Test an app in the browser

Drive your application's UI while its server uses the real vendor SDK inside a World. An HTTP request script is useful, but it does not exercise forms, login, cookies or the rendered result.

Start from the runnable exampleCopy Anchor Link

Use the browser signup cookbook. It includes the complete complete app, exact dependency versions, a World configuration helper and a eight-assertion Playwright test. Node 22.6 or newer and npm are required; no platform account or vendor key is needed.

The example registers its server as an app service after the Stripe twin. up waits for /health and records app-url. Read that URL with npx volter-world app-url browser-signup --root .; do not parse a credentials/env file to discover it. Run browser tests through world run so they receive the same app endpoint as the server.

Walk the user journeyCopy Anchor Link

1. Open the app URL and create an account using an example.com email and a fresh random password for this run. Never use a seed password or capture the password field.
2. The application creates a Stripe customer through its SDK. Assert the account heading, stored email and customer ID on the rendered page.
3. Assert the signed callback status. The receiver verifies the endpoint's signature before accepting an event.
4. Reload the account page. Assert the existing session still opens it.
5. Send an invalid signed callback and assert HTTP 400.
6. Sign out, then request /account with the browser session's request client. Require the redirect to /login, then sign back in with the displayed form and assert the account returns.

Use accessible roles/labels and assertions that wait for the expected state, not sleeps. Browser cookies authenticate to the app; they are separate from vendor keys and the console's session. The app's user/session state is not in the vendor log and is not erased by resetting a twin. Give parallel browser workers separate application and World roots, as CI isolation explains.

Read the score honestlyCopy Anchor Link

The provided test prints Workflow assertions: 8 / 8 passed only after all eight checks pass. This quick score measures the declared app workflow. The catalog separately reports supported operations, exercised vendor operations and replay; browser, DOM, source-code and transition coverage remain unmeasured unless that release's report says otherwise. Never label eight UI assertions as full vendor coverage.

After a failure, inspect the app error, World log and handler matches using recovery. Keep the test result with its exact dependencies, World config, clock and seed. Run a full stack explains adding databases and other services; reproduce a failure explains branches and their state limits.