How to Test MetaMask Snaps Custom Experiences

MetaMask Snaps let developers add wallet features, including experiences that can involve custom screens, notifications or support for networks beyond MetaMask’s built-in features. To test the user experience, you need to check more than whether your code runs: see what users are asked to approve, how the wallet displays each interaction and what happens when something goes wrong.

Use MetaMask Flask as your development wallet. It is intended for testing wallet features such as Snaps; it lets you exercise your Snap in a MetaMask environment rather than relying only on a standalone preview. Confirm the current setup and supported tools in MetaMask’s developer guidance before you begin, since development and release processes can change.

A useful test plan covers four things:

• First impression: Can a user understand what the Snap does before installing it?
• Permissions: Are requests necessary, understandable and tied to a clear feature?
• Interactions: Do screens, prompts and notifications appear at the right time?
• Recovery: Are errors, rejection and unavailable services handled safely?

Build and test with a dedicated account that holds no valuable assets. Treat every request to sign or approve as real, even in a development environment.

Set up a separate browser profile and install MetaMask Flask there. Keeping development separate from your everyday wallet reduces the chance of confusing test accounts with accounts that hold funds. Create or import a test-only account, and never enter a recovery phrase into your Snap or a test page.

Next, prepare the project using the current Snap development tooling and run its local development process. The exact setup can vary by project and tooling version, so follow the maintained MetaMask developer instructions rather than copying old commands from a tutorial. Your local Snap should be available to Flask through the development flow supported by that tooling.

Before opening the UI, check the basics:

1. The Snap builds and starts without errors.
2. Flask is using the intended development account and network.
3. Any RPC endpoint or external service is configured for testing.
4. Your test data contains no secrets or personal information.
5. You know how to stop the local process and remove the test installation.

There is no blockchain fee simply for opening a Snap. If your test involves a paid RPC service or an on-chain transaction, however, that provider or network may charge. Test-network tokens are not real funds, but they can still be useful for exercising wallet flows.

Write down the user journey before polishing individual screens. For example: a user discovers the Snap, reviews its purpose and requested permissions, approves or rejects installation, opens a feature, and then either completes an action or exits. Each decision is part of the experience—not just the screen your code renders.

For every permission, answer two questions: what feature needs it, and what will the user see if they decline? Remove requests that are not essential to the first useful version. Explain unfamiliar terms in plain language, and do not imply that a permission is required for a feature if it is not.

Test both branches of each decision:

User choice or condition	What to verify
Approves a request	The promised feature becomes available
Rejects a request	The Snap explains the consequence and remains stable
Closes a prompt	The user can return or safely leave
Revokes access later	The Snap detects the change and responds clearly

Also check whether your screens make clear which actions are informational and which may lead to a wallet approval or transaction. A good test asks a person unfamiliar with the feature to explain what they think will happen before they click. If their interpretation differs from your intent, revise the wording or flow.

Open the local Snap in Flask and test it as a wallet user, not only as its developer. Check the first installation prompt, each custom screen, and the transitions between them. Confirm that text fits, controls are understandable, and the interface remains usable when values are long, missing or unexpected. Wallet-rendered UI may not behave like a web page you control, so verify the actual display in Flask.

Try the complete journey with a fresh test installation, then repeat it after the Snap has already been installed. First-use and returning-user states often differ. Check that loading, success and failure states are distinguishable, that a user can dismiss a view, and that repeated clicks do not trigger duplicate actions.

Use a short manual checklist:

• Can you identify the Snap’s purpose from its first prompt?
• Does each button say what it will do?
• Are important details visible without relying on colour alone?
• Does the screen explain what happened after success, rejection or cancellation?
• Can you get back to a known state after an error?

Test with realistic but non-sensitive sample values. Include unusually long names, empty responses and malformed data. A screen that looks correct with one ideal example may still confuse users or overflow when a real service returns something unexpected.

Use automated tests for repeatable behaviour, then verify the same flows manually in Flask. MetaMask Snap development has an end-to-end testing environment for Jest, which can help check interactions across a Snap’s expected user flow. Confirm that your project’s current tooling supports the test setup you choose; do not assume an older example still matches a current SDK version.

Automate the parts that should stay consistent: input validation, permission-dependent behaviour, responses to user choices, and handling of rejected or failed requests. Include tests for expected output and for cases where a service returns an error, no result or an unexpected value. If your Snap presents custom UI, check that the right content and actions are produced for each state.

Keep tests independent of real funds and production credentials. Stub external services where practical, and make the test clearly fail if a required configuration is missing rather than silently using a live endpoint. Run automated checks after changes to UI text, permissions, network calls or dependencies.

Automation cannot tell you whether a prompt feels trustworthy or whether a user understands a consequence. Ask someone unfamiliar with the project to complete a task while describing what they expect each action to do. Use those observations to refine wording, then keep the successful and failure paths in your regression tests.

If your Snap reads blockchain data or calls an external service, test the connection as part of the user experience. Verify how the interface behaves when the network is slow, unavailable, rate-limited or returns incomplete data. Give users a clear status and a way to retry where retrying is safe; do not show stale information as though it were current.

For a Snap that leads to a wallet action, inspect the handoff carefully. The user should be able to understand what they are being asked to approve in MetaMask, and the Snap should report the result accurately. Test approval, rejection, cancellation and a transaction that remains pending or fails. Never design the interface to pressure someone into signing, or describe a transaction as successful before the wallet or network confirms it.

Use a test network or a mocked response for development when it can exercise the required behaviour. If a public RPC provider is involved, check its limits and terms; an endpoint that works during a brief demo may not be suitable for production. Costs can come from RPC usage, paid services or network fees, but the Snap itself does not guarantee that any of those are free.

Keep a record of which network, account and service configuration each test uses. This makes it easier to spot a test that passed only because it was pointed at the wrong environment.

Before sharing a Snap beyond your development setup, run a release check against the current MetaMask requirements. Confirm that the package builds cleanly, permissions still match the feature, and every interface path has been tested in the intended wallet environment. The supported review, publishing and installation process may change, so check the current developer guidance instead of relying on a remembered allowlisting or release procedure.

Avoid these common mistakes:

• Testing only the happy path: Include rejection, timeouts, missing data and repeated actions.
• Requesting broad permissions early: Ask for the minimum needed and explain the benefit before the prompt.
• Treating a UI preview as a wallet test: Verify the whole flow inside Flask.
• Using a personal wallet: Keep tests isolated from accounts with valuable assets.
• Leaving live services in test builds: Make the target network and endpoint explicit.
• Overstating what the Snap does: Be precise about data sources, limitations and whether a displayed result is final.

Finally, give testers a concise task list and ask them to report where they hesitated, what they thought a permission meant, and what they expected after an error. Fix misunderstandings before adding more features. A polished interface is not enough if users cannot predict what a prompt will do or recover when a request fails.