What are fixtures and how do you build a custom one?

Fixtures replace the beforeEach and afterEach pattern with typed, composable dependencies. A test asks for what it needs by name, and Playwright resolves the dependency graph, runs setup, hands over the value and runs teardown in reverse order.

import { test as base } from "@playwright/test";
import { CartPage } from "./cart-page";

type Fixtures = {
  cartPage: CartPage;
};

export const test = base.extend<Fixtures>({
  cartPage: async ({ page }, use) => {
    const cartPage = new CartPage(page);
    await cartPage.open();
    await use(cartPage);
    await cartPage.clear();
  },
});

Test scope versus worker scope

• Test-scoped fixtures are created fresh for each test and are the default
• Worker-scoped fixtures are shared by all tests in the same worker process
• Built-in fixtures include page, context, browser, request and browserName
• An auto fixture runs without being named in the test signature
• Fixtures can depend on other fixtures, including built-in ones

type WorkerFixtures = {
  accountId: string;
};

export const test = base.extend<{}, WorkerFixtures>({
  accountId: [async ({}, use) => {
    const id = await createAccount();
    await use(id);
    await deleteAccount(id);
  }, { scope: "worker" }],
});

Worker scope is useful for expensive resources such as an authentication token or a seeded tenant, but it introduces shared state. If tests mutate the shared resource, they can affect each other even though browser contexts are isolated. Prefer test scope unless the setup cost is genuinely high.