DEV Community: Chidume Kenneth

Why Your Playwright Tests Fail on Protected Routes (And the Simple Fix)

Chidume Kenneth — Sat, 14 Nov 2026 15:34:06 +0000

Introduction
When I first started testing protected routes with Playwright, everything looked correct. From login to UI and JWT authentication, everything worked perfectly.

But the moment I tried to access a protected page in my E2E tests with Playwright, I kept running into a frustrating issue: 401 Unauthorized errors.

At first, it didn’t make sense. The same flow worked perfectly in the browser. So Why was Playwright behaving differently?

I even tried running the login test first before the protected route test, but it still did not work!

The issue wasn’t in my backend logic. It was in how browser authentication state works during automated testing.

Playwright does not automatically share authentication state between tests or sessions.

In this article, I’ll show you the minimal and correct way to fix this using storageState.

The Problem
On a real device, you log in once, and the token is stored. (in cookies or localStorage). With this, you stay authenticated as long as the token is still valid.

But in Playwright, things work differently because each test runs in a fresh browser context, and therefore, there are no cookies, localStorage, or tokens available for the next test.

So even if you login in one test, the next test starts as a completely new user.

Hence, the 401 Unauthorized error, and then the test eventually timing out.

What Doesn’t Work
Running login in one test and expecting another test to stay authenticated:

//login test
test.describe('login page', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:5173/sign-in')
  })
  test('should redirect to home page on sign in', async ({ page }) => {
    await page.getByPlaceholder('Email').fill('elysian@gmail.com')
    await page.getByPlaceholder('Password').fill('12345')
    await page.getByRole('button', { name: 'sign in' }).click()
    await expect(page).toHaveURL(/\/$/)
  })
})

//listing page(protected route) test
test.describe('listing page', () => {
  test('should have empty fields on initial load', async ({ page }) => {
    await page.goto('http://localhost:5173/create-listing')
    await expect(page.getByPlaceholder('Name')).toBeVisible()
    await expect(page.getByPlaceholder('Address')).toHaveValue('')
  })
})

As you can see below, our login test passed, but then the listing page test, which required authentication to be accessed, failed!

E2E test demonstration with Playwright

How to Fix It
The clean solution is to save the authentication state after login:

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

This code above saves the current browser session (cookies + localStorage) into a file called auth.json in the root folder(since we did not specify any folder in the path)

So we add the above code immediately after the login button click, and after navigation has completed(to ensure the login was successful) in the login test:

test.describe('login page', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:5173/sign-in')
  })
  test('should redirect to home page on sign in', async ({ page }) => {
    await page.getByPlaceholder('Email').fill('elysian@gmail.com')
    await page.getByPlaceholder('Password').fill('12345')
    await page.getByRole('button', { name: 'sign in' }).click()
    await expect(page).toHaveURL(/\/$/)

    // Here we save the login state
    await page.context().storageState({ path: 'auth.json' });
  })
})

page.context: This refers to the browser context, not just the tab. And this browser context contains the cookies, localStorage, and authentication state.

storageState: This is a Playwright method that extracts and saves all auth-related browser data

{path:'auth.json'}: This tells Playwright to save everything into a file called auth.json.

So it creates something like this inside the auth.json file:

{
  "cookies": [
    {
      "name": "token",
      "value": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9*********",
      "domain": "localhost",
      "path": "/",
      "expires": 1774197120.965915,
      "httpOnly": true,
      "secure": false,
      "sameSite": "Strict"
    }
  ],
  "origins": []
}

Now we configure Playwright to load and use the storageState we set above by adding this line inside the describe block of the test that involves a protected route:

test.use({ storageState: 'auth.json' })

test.use(): is used to configure how your tests run on Playwright.

storageState: is one of the options passed to test.use(). This tells Playwright to load the saved login session.

auth.json: is the name of the file where we saved the login session

Full code

// @ts-check
import { test, expect } from '@playwright/test'

test.describe('login page', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:5173/sign-in')
  })
  test('should redirect to home page on sign in', async ({ page }) => {
    await page.getByPlaceholder('Email').fill('elysian@gmail.com')
    await page.getByPlaceholder('Password').fill('12345')
    await page.getByRole('button', { name: 'sign in' }).click()

    await expect(page).toHaveURL(/\/$/)
    await page.context().storageState({ path: 'auth.json' })
  })
})


test.describe('listing page', () => {
  test.use({ storageState: 'auth.json' })
  test.beforeEach(async ({ page }) => {
    await page.goto('http://localhost:5173/create-listing')
  })
  test('should have empty fields on initial load', async ({ page }) => {
    await expect(page.getByPlaceholder('Name')).toBeVisible()
    await expect(page.getByPlaceholder('Address')).toHaveValue('')
  })
})

This works because storageStatesaves your cookies, localStorage, and session data, so that Playwright can load your app as if the user is already logged in.

Note: Ensure you add the login session file(auth.json in our case) to .gitignore file to avoid exposing your application session

Final Takeaway
So, if your Playwright tests keep failing on protected routes, it’s not your backend, nor is it your JWT logic, but because it is missing authentication state in the test environment

Fix it once with storageState, and your E2E tests become stable and predictable.

Story of a Component and a Developer’s Adventure using Bit

Chidume Kenneth — Sat, 14 Nov 2026 15:21:33 +0000

Ada works as a React developer in a tech firm where they provide solutions for travelers, they have an app where travelers, hikers can look up their places of interest and it shows them high tour points from the position to the tour point relative to their current location.

It happens that Ada built a component that that marks the direction of a point on the Map to another point. She shows it to her fellow workmates in her team and they were like

“Wow!! That’s lovely. Can you share it with me?”

“Of, course” she responds

Now, she tries sharing the component, but she is faced wih a serious problem.

“How do I go about this?”

She has different options:

Copy and Send the component

Ada can copy the components and send them over to her teammates. But that’s not so efficient. If she makes a modification to the components, she will have to re-send the files over again. And her teammates would have to delete the previous files and paste the newly modified ones.

Share with Git and NPM

Copying and pasting are time-consuming and very tedious. She may try to share the files with NPM. So her teammates can simply use Git to install the components from NPM.

She will have to create another project for the component, a React library project.

She will initialize another Git repository, install the necessary tools like Rollup, to enable her to compile the component. Build the component and publish the library.

The overhead here is that she is forced to create another repo for the component and add it to her list of repos to maintain. If she comes up with another component her teammates like she will have to create another repo and share the component to NPM.

Share with Bit

Somehow, she hears about Bit, a cloud platform that enables one to share components out from their project without an extra Git repo(s).

Ada smiles because this is what she has been looking for. She looks up the Bit docs and finds out that it is super easy to use it.

She fires up her dev environment, installs the Bit CLI, and initializes a Bit environment in her project.

npm i bit-bin -g
bit init

Then she adds the component’s entry point using Bit’s add command. Let’s say the project looks like this:

trv-react-prj
    src/
        - /utils/
            ...
        - /map/
            ...
        - ...
        -index.js
        -App.js
    - package.json
    - bit.json
    - .bitmap

Bit forces us to use the Single Responsibility Principle, that a component must have only one reason to change and must be responsible for only one thing.

Components are divided into container and presentational components. Containers hold the business logic of the project and are not shareable, while the Presentationals hold the UI view of the project. These are shareable meaning they can be used in other projects without touching them or having any reason to change them — that’s what SRP says. So you see, Presentationals are components that obey SRP and are shareable to the Bit cloud platform.

This will force Ada and her teammates to refactor their code to make it suitable for Bit launch.

trv-react-prj
    src/
        - /utils/
            ...
            -index.js
        - components
            - /map/
                ...
            - clients/
                ...
            - index.js
        - ...
        -index.js
        -App.js
    - package.json
    - bit.json
    - .bitmap

See, they have changed their codebase, so every component is in the component folder and inside the folder, the components have a separate folder, an index.js file at the component folder exports them all.

Ada can now pick out her component, map folder and add it to Bit's tracked files:

$ bit add src/components/map
tracking 5 new components

Then she imports a React compiler:

bit import  bit.envs/compilers/react --compiler
the following component environments were installed
- bit.envs/compilers/react@0.0.14

This compiler is a tool required by Bit to help it build components in isolation.

Learn about Medium’s values
Ada will go to bit.dev to create a collection. She names the collection travellers-prj.

Now, she will tag her tracked component with a version:

$ bit tag --version 0.01

Then, she will export the map component to the collection:

$ bit export @travellers-prj.map

She tells her teammates it and gives them a link to the map’s Bit link. They are perplexed by how simple the stuff looks, the Bit playground and how they could import the component to their project using NPM and any other project.

yarn add @travellers-prj.map
npm i @travellers-prj.map

She tells them all about Bit and how it was able to save her:

Copying and sending components to them
Creating extra Git repos just to share a component.

Her project lead is happy and announces they will use Bit from now on. And also they refactor all their project to Bit’s best practices.

Teams that scale code-sharing and code reuse enjoy faster development cycles and simpler maintenance.

Ada was able to easily share her code with her teammates using Bit. Her teammates can reuse her code in their projects. There will be no need to rewrite codes from scratch, code in a project can used in another.

Bit is designed to help teams scale the sharing and management of components to hundreds and even thousands of components. From that philosophy, it takes care of the components’ entire lifecycle from development to deployment so that your team can share and manage any number of components for any number of developers. This includes:

Managing and publishing any number of components from any number of repositories/libraries at any scale with 0 overhead.

Ada can create more components and share them without creating repositories for them. Bit is left for the task, it will isolate, build and track the components for her.

Creating discoverability for shared components so that every developer can easily find and choose components

Ada after moving her components to the Bit.dev, she was able to give her teammates the link. And they were awwed by how they were able to play around the component in Bit’s playground before using them. The Bit’s playground provides enhanced discoverability for the components you share. It’s designed to help developers quickly find and choose the components they need through a universal hub with a rich, visual and interactive experience.

Increasing the adoption of shared components by removing the main barriers and encouraging collaboration.

The components shared on Bit aren’t for the maintainers, Bit enables it to be for the consumers of the components.

All this above means you can do more than install a package; you can actually develop components from any project and sync changes between projects.

Just like Ada did, she move her map component her teammates liked to Bit. This map component can be developed by her teammates and the changes synced to other projects.

This becomes possible because, unlike package managers, Bit manages source code for shared code across different repos. So you can export a component from one repo, import it into another, make changes and sync them.

When Ada built her map component using Bit’s bit build, Bi actually built an isolated React library project for her and extra Git repo. In this case, she has nothing to do with it, Bit does everything for her while she continues working on her project.

Conclusion
Bit is an awesome tool you can’t just pass by. Ada was finally saved from the stress of sharing her component with her teammates when she stumbled upon Bit.

Bit is fast, user-friendly, and powerful. Try it out today, whether working on a team or working solo.

Thanks !!!