Breadcrumbs

How to Reuse Login State Across Playwright Tests with storageState

Playwright's storageState lets you save authenticated browser state and reuse it across tests instead of repeating the complete login flow every time.

A typical Playwright setup authenticates once, saves the state, and then loads it for subsequent tests.

Leapwork Play lets you record the login journey once and reuse that Login test case across other Playwright workflows. Instead of recording or maintaining the same login steps in every test, add the reusable Login test case and continue with the authenticated journey.

Try Leapwork Play →

How do you reuse authentication with storageState in Playwright?

After authentication, Playwright can save the browser context state:

await page.context().storageState({
  path: 'playwright/.auth/user.json'
});

Other tests can then use that saved state:

use: {
  storageState: 'playwright/.auth/user.json'
}

This avoids performing the complete UI login before every test.

The important consideration is that the stored authentication state must still be valid when the test runs.

How does Play make the login flow reusable?

With Leapwork Play, record the login journey once and save it as its own test case. Other tests can then add that login test case as a reusable step instead of recording the same authentication flow again.

During execution, Play runs the reusable Login test case first and then continues with the remaining steps in the calling test.

Choosing between Playwright storageState and a reusable Play login flow

Use storageState when you need to reuse a saved, already-authenticated browser session across Playwright tests.

Use a reusable Play login flow when you want to centralise the login journey itself, so multiple Play tests can call the same maintained login test case before continuing with their own workflows.

Requirement

Approach

Reuse previously authenticated browser state

Playwright storageState

Avoid duplicating the login steps across Play tests

Reusable Play login test case

Maintain the login workflow in one place

Reusable Play login test case

This distinction matters because a stored session and a reusable login workflow are not the same thing.

How Play extends the Playwright authentication workflow

With Playwright

With Leapwork Play

Implement the authentication setup in your Playwright test architecture

Record the login journey as a Play test case

Use storageState when you want to reuse authenticated browser state

Reuse the Login test case when another workflow needs to authenticate

Maintain shared authentication code/configuration

Maintain the recorded login journey in one reusable test case

Tests consume the authentication setup

Tests can include Use test case: Login and continue with their own steps

Play complements Playwright by making the login journey itself reusable as part of the test workflow, while storageState remains the Playwright mechanism for reusing saved authenticated browser state.

When should you use storageState?

Use storageState when:

  • logging in before every test is unnecessarily repetitive;

  • the authenticated state can safely be reused;

  • the session remains valid for the tests that consume it.

Do not assume saved authentication remains valid indefinitely. Sessions can expire or be invalidated by the application.

When is a reusable Play login useful?

Use a reusable login test case when several Play tests need to perform the same login journey.

Instead of maintaining:

Test A → login → workflow A
Test B → login → workflow B
Test C → login → workflow C

you can structure the tests around:

Reusable Login
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
A     B    C

When the login journey changes, the reusable flow provides one place to maintain that shared workflow.

Best practices

  • Record a common login journey once in Play and reuse the Login test case from workflows that require the same authentication journey.

  • Use storageState when the requirement is specifically to reuse authenticated browser state.

  • Keep authentication logic centralized rather than duplicating login steps across tests.

  • Make sure stored authentication state is still valid when it is consumed.

  • Keep credentials and authentication artifacts out of source code.

  • Update the reusable login workflow when the application's authentication journey changes.

Troubleshooting

Problem

What to check

storageState no longer authenticates the test

Check whether the saved session expired or was invalidated

Tests repeatedly contain the same login steps

Move the common login journey into a reusable Play test case

Login UI changes

Update the reusable login workflow

Authentication works locally but not elsewhere

Check credentials, session validity, environment, and identity-provider access

Different tests require different users

Keep the authentication workflow and required user context explicit
play-docs-cta-banner-3.png

Frequently asked questions

What is Playwright storageState?

storageState lets Playwright save browser-context authentication state so it can be loaded by subsequent tests.

Does storageState mean I never need to log in again?

No. The stored authentication state can expire or be invalidated. Your test strategy needs to account for session validity.

How does Leapwork Play reuse login flows?

Record the login journey as its own Play test case. Other tests can then add that Login test case as a reusable step and continue with their authenticated workflow.

Is a reusable Play login the same as storageState?

No. storageState reuses saved browser authentication state. The demonstrated Play workflow reuses the login journey itself by calling a reusable Login test case.

Why make login a reusable test case?

It prevents the same login sequence from being duplicated across multiple tests and gives you one reusable workflow to maintain.