Advanced Playwright — Network Interception & Auth

1 The Hook

A test suite for a NZ logistics platform has 150 tests. Every test starts with a login. Login takes 2.5 seconds: the auth service has to round-trip, issue a token, redirect, and load the dashboard. Total time spent on auth alone: 375 seconds per CI run, before a single assertion.

The SDET implements auth state storage — log in once during global setup, save the browser storage state to a JSON file, and load it in every test instead of logging in again. New auth time across 150 tests: 8 seconds.

Time saved per CI run: over 6 minutes. On a team doing 20 PRs a day, that is 2 hours of engineering time recovered daily from one afternoon’s work.

2 The Rule

3 The Analogy

4 Watch Me Do It

Auth state: log in once, reuse everywhere.

// global-setup.ts
import { chromium, FullConfig } from '@playwright/test';

async function globalSetup(config: FullConfig) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('http://localhost:3000/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL!);
  await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD!);
  await page.getByRole('button', { name: 'Log in' }).click();
  await page.waitForURL('**/dashboard');
  // Save cookies + localStorage to a file
  await page.context().storageState({ path: 'auth.json' });
  await browser.close();
}

export default globalSetup;

// playwright.config.ts — add these two lines:
globalSetup: './global-setup.ts',
use: { storageState: 'auth.json' },

Every test now starts with an already-authenticated browser context. The login page is never loaded during the test run itself.

Network interception: mock an Revenue NZ API response.

test('handles Revenue NZ validation error gracefully', async ({ page }) => {
  // Intercept the Revenue NZ number validation API and return a 422
  await page.route('**/api/ird/validate**', async route => {
    await route.fulfill({
      status: 422,
      contentType: 'application/json',
      body: JSON.stringify({
        error: 'IRD_INVALID',
        message: 'The Revenue NZ number provided is not valid',
      }),
    });
  });

  await page.goto('/enrolment/step-2');
  await page.getByLabel('Revenue NZ Number').fill('000-000-000');
  await page.getByRole('button', { name: 'Validate' }).click();

  await expect(page.getByRole('alert')).toContainText('not valid');
  await expect(page.getByRole('button', { name: 'Next' })).toBeDisabled();
});

Route abort: simulate a network failure.

test('shows offline message when API is unreachable', async ({ page }) => {
  await page.route('**/api/**', route => route.abort('failed'));
  await page.goto('/dashboard');
  await expect(page.getByText('Unable to connect')).toBeVisible();
});

route.abort() drops the connection entirely. Use it to test how the UI handles a total network failure, not just a server error response.

5 When to Use It

Auth state — always, for any project where tests require authentication. No exceptions.

Network mocking — for testing error states, edge cases, rate limiting, and third-party API dependencies you cannot control: Revenue NZ, RealMe, Stripe, Open Banking APIs. If a test relies on a third-party returning a specific error code, mock it. You cannot control when that third party returns that code in a real environment.

Do not mock your own API when testing integration between front end and back end. Use mocking to isolate what you are testing; use real API calls when integration is what you are testing.

6 Common Mistakes

7 Now You Try

8 Self-Check

Click each question to reveal the answer.

9 ISTQB Mapping

10 Next Steps