Skip to content

Chapter 5 of 8

Authentication, State, and Data Isolation

Logging in once and reusing the session across tests is one of the biggest speed and reliability wins in an E2E suite. The standard mechanism is storageState, a JSON file containing cookies and localStorage that Playwright can preload into a context via test.use({ storageState: 'storageState.json' }). The recommended place to create that file is a globalSetup script that programmatically logs in (ideally through a test-only auth endpoint rather than the full UI) and writes the result into an .auth directory under the test project, e.g. e2e/.auth/storageState.json. Real-user secrets must never be committed; read credentials from env vars and treat the state file as an artifact.

Different roles deserve different sessions. Generate storageState.admin.json and storageState.user.json separately, then attach them with test.use({ storageState: ... }) inside the relevant describe blocks or projects. SSO and 2FA flows are notoriously brittle under UI automation, so prefer a storageState created manually once, an API-based test login, or a non-production auth bypass. After login, assert both the URL change and a unique logged-in UI element (such as a user menu) so a false-positive login is hard to slip through. Storage states should be paired with separate browser contexts per test to prevent auth or cookie bleed.

Deterministic tests need deterministic data. Create test-only seed/reset endpoints and call them from the built-in request fixture (await request.post('/api/test/seed', { data })) in test.beforeEach or beforeAll where appropriate. Be cautious with beforeAll for UI state: shared mutable data across workers is a frequent source of flakiness, so prefer per-test isolation or API seeding. For per-test uniqueness, prefix data with a run id (timestamp or UUID) and store it on testInfo or in an env var so cleanup scripts can find what each test created.

All chapters
  1. 1Foundations: Installing and Configuring Playwright
  2. 2Selectors, Locators, and Resilient Tests
  3. 3Assertions, Waits, and Avoiding Flakiness
  4. 4Running, Tagging, and Debugging Tests
  5. 5Authentication, State, and Data Isolation
  6. 6Visual Regression and Snapshots
  7. 7CI/CD, Reports, and Parallel Execution
  8. 8Workspace Workflows and AI Agent Collaboration

Drill it

Reading is not remembering. These come from the Anki Playwright Agents deck:

Q

Playwright (Node): minimal setup?

npm i -D @playwright/testnpx playwright installnpx playwright test

Q

Where do Playwright tests live?

Common: ./tests or ./e2e (you choose). Configure testDir in playwright.config.ts so agents know where to add new tests.

Q

Key playwright.config.ts settings?

use.baseURL, webServer (start app), projects (chromium/firefox/webkit), retries/workers, reporter (html + junit), trace/video/screenshot policies.

Q

How do I auto-start my app for tests?

Use playwright.config.ts webServer: { command: "npm run dev", url: "http://127.0.0.1:3000", reuseExistingServer: !process.env.CI }.