Fixtures

Introduction

Fixtures is a practical Playwright skill for engineers building suites that run reliably across browsers, devices, and CI jobs. Instead of memorizing syntax, learn the production reason behind it: what risk it reduces, what evidence it gives, and how it changes the way a team ships software.

Purpose of this lesson

Story: An SDET split one slow suite into Playwright projects, reused storage state, mocked expensive APIs, and ran workers in parallel. Feedback dropped from 90 minutes to under 18. In this lesson, fixtures are dependency injection for Playwright tests. That is the difference between a test that merely runs and a test that helps a team decide.

Understanding the topic

Why this exists: Fixtures are dependency injection for Playwright tests. The runner is the execution platform: projects, workers, fixtures, retries, timeouts, tags, and reports.

• Real problem solved: Fixtures reduces ambiguity when browser behavior, data, timing, or infrastructure changes.
• Production use: multi-browser regression, PR gates, sharded CI, smoke suites, visual projects, and authenticated projects.
• Beginner misuse: Putting every test into one slow bucket and calling it regression.
• Elite SDET move: Design execution tiers: fast PR smoke, focused feature suites, nightly cross-browser regression, and release validation.

Visual explanation

Mental model:

Config
  ├─ Project: chromium smoke
  ├─ Project: firefox regression
  └─ Project: webkit mobile
       ↓
Workers + fixtures + reports

Informative example

A practical example for Fixtures:

// playwright.config.ts
export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  projects: [
    { name: "chromium", use: { ...devices["Desktop Chrome"] } },
    { name: "webkit", use: { ...devices["Desktop Safari"] } },
  ],
}); // fixtures

Execution workflow

Real-world use

In real teams, Fixtures matters because product code changes every week. The test must still tell a useful story: what user behavior was protected, what state was expected, what evidence was captured, and whether the failure belongs to the app, the test, the data, or the environment.

Best practices

• Use projects to model browsers, devices, locales, auth roles, and visual modes.
• Tag tests by risk and runtime.
• Keep retries visible and track retry rate.
• Move expensive setup into worker fixtures only when it is safe.

Common mistakes

• Using retries as a substitute for fixing flakes.
• Running stateful tests in parallel without isolated data.
• Setting global timeouts so high that failures waste CI minutes.

Debugging tips

• Check the worker, project, retry number, and trace artifact together.
• Run a failing test with the same project config locally.
• If parallel-only failures appear, inspect shared data and global state.

Advanced interview questions

Summary

Fixtures is valuable when it makes browser automation faster, clearer, and easier to debug under real product change.