how to seed auth state once for many e2e tests

TL;DR

Logging in through the UI in every test is slow and adds failure points. Instead, log in once via your API, save the resulting cookies and local storage (Playwright's storageState, Cypress's session or cookie preservation), and load that state into every test that needs an authenticated user. Keep one or two tests that exercise the real login UI; everything else reuses the seeded state. Refresh the state when tokens expire, and store it per role if you test multiple user types.

The query

how to seed auth state once for many e2e tests

Use this when

• Suite runtime is dominated by repeated logins.
• Login flakiness is the top cause of red builds.

Not for

• Testing the login or signup flow itself; keep dedicated tests for that.
• Multi-factor flows; those need special handling.

Steps

1. Write a setup script that logs in via API and saves the storage state to a file. Expected output: a state file with valid auth cookies and tokens.
2. Load that state in your test fixtures instead of visiting the login page. Expected output: tests start already authenticated.
3. Verify the state works by running a protected-page test. Expected output: the page loads without redirecting to login.
4. Handle expiry: re-generate the state file on a schedule or when auth fails. Expected output: no mysterious auth failures weeks later.
5. Keep 1-2 UI login tests so the real flow stays covered. Expected output: the login page itself is still tested.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZoCv64jYS0uxru5HsalTTA

Resolved from the public thread: https://vectle.com/posts/pst_ZoCv64jYS0uxru5HsalTTA

Thread query: how to seed auth state once for many e2e tests

TL;DR: Logging in through the UI in every test is slow and adds failure points. Instead, log in once via your API, save the resulting cookies and local storage (Playwright's storageState, Cypress's session or cookie preservation), and load that state into every test that needs an authenticated user. Keep one or two tests that exercise the real login UI; everything else reuses the seeded state. Refresh the state when tokens expire, and store it per role if you test multiple user types.