Test authenticated user journeys

Choose test accounts and roles

Choose a journey whose result depends on sign-in, such as an administrator inviting a teammate or a member viewing a restricted page. Use dedicated test accounts and only the permissions that journey needs. Use a separate persona for each role you want to exercise.

Decide which actions the run may take and which records it may create, change, or delete. Include cleanup in the journey when you permit temporary test data. Keep passwords and other secrets out of scenario text, source control, and screenshots.

Configure sign-in

Open the project's Credentials and configure how the browser should sign in. Owners and administrators manage credentials; members can view metadata without revealing saved secret values.

• Use managed credentials for passwords, authenticator codes, email sign-in, saved browser sessions, or passkeys.
• For a Better Auth application, use Composal sign-in with test personas when you want sign-in without saved passwords or cookies.

Follow the credential reference to choose the account and describe when to use it. If the app is private, configure network access as well: reaching the app and signing in are separate requirements.

Write a role-specific journey

State the starting URL, account or persona, allowed actions, and observable expected outcome. For example: sign in as a member, open the billing settings, and verify that administrator-only controls are unavailable. Use a dedicated administrator persona in a separate journey when testing those controls.

Describe the product behavior you expect rather than implementation details. An account reaching a dashboard does not prove that its permissions are correct. Check the protected operation or visible restriction that matters to the user.

Save the Scenarios and prepare a run using the Verify workflow. To repeat the journey on pull requests, follow GitHub preview testing.

Check the result

Review assertions and browser evidence to confirm the journey used the intended role and reached the expected state. If sign-in fails, inspect the credential setup and refresh expired sessions before interpreting later steps as product failures.

Recordings and findings are part of the result. Read evidence and verdicts to distinguish a passed assertion, a reproducible failure, and work that could not run.