Test Data, Fixtures and Hooks

Why it matters

Many unreliable automated suites fail because of state, not because of the product. A test passes alone and fails in the full run because an earlier test changed the shared account; a run fails on Monday because the coupon the test relies on has expired; leftover orders from thousands of runs slow a list page until its tests time out. How a suite sets up and cleans up decides whether a red result means a defect or just noise, and noise teaches a team to ignore red results.

Setup also decides maintenance cost. When the sign-in flow changes, a fixture is one place to update; twenty copied setup blocks are twenty. Data-driven tests let you add a case by adding a row, and a readable table lets a reviewer or a product owner check the cases without reading code.

Where test data lives in an automated test

A test runner executes tests unattended, in any order and often in parallel, so every value a test depends on must come from somewhere the test controls. A test that silently relies on a record someone created by hand in a shared environment will fail on the day that record is edited or deleted, and the failure will look like a product defect.

Two rules apply wherever the data lives. A test owns the data it changes: only read-only reference data, such as the list of countries or a product catalogue no test edits, may be shared. And a field that must be unique gets a unique value per run, for example sara+${runId}@example.com, so a second run or a parallel worker does not fail with "already exists".

The data itself can live in four places; choose by what the reader of the test needs to see.

• Inline in the test: the one or two values that explain the test, such as quantity: 0 in a test named "rejects a zero quantity". Keep the value that matters visible next to the assertion.
• A builder or factory function: makeCustomer({ country: "JO" }) returns a complete, valid record with sensible defaults, and the test overrides only the field it is about. When a new mandatory field appears, you change the factory once.
• A data file: a CSV or JSON table in the repository, next to the tests, when many cases share one test body. It is reviewed and versioned like code.
• State created before the test: records that must exist, created through the API or a seed script rather than by clicking through screens, which is slower and fails for reasons the test is not about.

Try it: Test Data Factory Try it: UUID Generator

Hooks: code the runner calls before and after tests

Most runners offer four hooks. beforeAll runs once before the first test of a file or group, beforeEach before every test, afterEach after every test and afterAll once after the last one. Jest and Vitest use exactly these names; Playwright Test writes them as test.beforeEach and so on; JUnit 5 uses the annotations @BeforeAll, @BeforeEach, @AfterEach and @AfterAll. pytest supports simple setup and teardown functions too, but its usual tool is the fixture, described next.

For each test the order is: the beforeEach hooks, the test body, the afterEach hooks. In nested groups, the outer group's beforeEach runs before the inner one's. The important property is that after-hooks run even when the test fails. A failed assertion stops the test body at that line, so cleanup written as the last lines of the body never runs, while cleanup in afterEach does.

Use beforeEach for state that tests change, so each test starts fresh. Use beforeAll only for expensive setup that tests read but never change, such as starting a stub server: mutable data created once and changed by several tests makes the result depend on the order the tests ran in. In Playwright Test, beforeAll runs once per worker process, and again in the new worker that replaces one after a test fails, so it must be safe to run more than once.

import { test, expect } from '@playwright/test';

test.describe('saved addresses', () => {
  const created: string[] = [];              // ids of addresses these tests created

  test.beforeEach(async ({ page }) => {
    await page.goto('/account/addresses');   // every test starts on the same page
  });

  test.afterEach(async ({ request }) => {      // request: an HTTP client for the API
    for (const id of created) {              // runs even when the test failed
      await request.delete(`/api/addresses/${id}`);
    }
    created.length = 0;
  });

  test('lists an address added through the API', async ({ page, request }) => {
    const res = await request.post('/api/addresses', { data: { city: 'Riyadh' } });
    created.push((await res.json()).id);
    await page.reload();
    await expect(page.getByText('Riyadh')).toBeVisible();
  });
});

Fixtures: setup a test asks for by name

A fixture packages three things: the setup, the value the test receives, and the teardown. The test asks for a fixture by name instead of calling setup code itself. In Playwright Test, page (a browser page) and request (an HTTP client for calling the API directly) are built-in fixtures, and you add your own with test.extend: code before await use(value) is setup, the test runs during use, and the code after it is teardown, which runs whether the test passed or failed. In pytest, a fixture is a function marked @pytest.fixture that a test requests by naming it as a parameter; it hands over the value with yield, and the code after yield is the teardown.

Compared with hooks, fixtures run on demand: only the tests that ask for customer pay for creating one. They compose: an order fixture can ask for the customer fixture, and teardown runs in reverse order, so the order is deleted before its customer. They have a scope: per test by default, or shared more widely, per worker in Playwright or per module or session in pytest, for expensive things the tests only read. In Playwright Test, a fixture is by default set up lazily, just before the first hook or test that asks for it: page, used by a beforeEach hook, is ready before that hook runs, while a customer that only the test body asks for is created after the beforeEach hooks. Test-scoped fixtures are torn down after the afterEach hooks.

Keep the values that matter visible. A fixture should hide how a customer is created, not what kind of customer the test needs; when a test depends on a detail such as the customer's country, pass it in or create a separate, clearly named fixture.

// fixtures.ts
import { test as base, expect } from '@playwright/test';
import { randomUUID } from 'node:crypto';

type Customer = { id: string; email: string };

export const test = base.extend<{ customer: Customer }>({
  customer: async ({ request }, use) => {
    // setup: a fresh customer for this test only
    const email = `sara+${randomUUID()}@example.com`;
    const res = await request.post('/api/customers', { data: { email } });
    const customer: Customer = await res.json();

    await use(customer);                     // the test runs here

    // teardown: runs after the test, passed or failed
    await request.delete(`/api/customers/${customer.id}`);
  },
});
export { expect };

// orders.spec.ts
import { test, expect } from './fixtures';

test('a new customer has no orders', async ({ request, customer }) => {
  const res = await request.get(`/api/customers/${customer.id}/orders`);
  expect(await res.json()).toEqual([]);
});

Try it: Fake User Generator

Cleanup: leave the environment as you found it

Leftover data is not harmless. It fills the lists and search results other tests assert on, collides with unique constraints, and confuses manual testers in a shared test environment. Every test that creates something needs a plan for removing it, or an environment that is thrown away after use.

• Put cleanup in an after-hook or in fixture teardown, never only at the end of the test body.
• Delete exactly what the test created, by id. Never clean up with a broad query such as "delete every customer whose email ends in example.com": in a shared environment it removes other people's data and the data of parallel runs.
• Keep setup steps separate, so that one failing step does not skip the teardown of the steps before it; the pytest documentation recommends one state-changing action per fixture for this reason.
• Make teardown tolerant of a record that is already gone, for example because the test deleted it itself, but report any other cleanup failure instead of swallowing it.
• Prefer data that disposes of itself where the setup allows it: a database transaction rolled back after each test, in integration tests that share the database connection with the code under test; a fresh container or a reset environment per run; or a separate tenant per run.
• Mark created data with a run prefix such as AT-20261002-0412-, so a scheduled job can find and remove what crashed runs left behind.

Worked example: one test, a table of discount codes

Requirement: "The code SAVE10 gives 10% off orders of 200.00 SAR or more and is refused below that with a minimum-order error. Codes are not case-sensitive. An expired or unknown code leaves the total unchanged and shows an error." Six near-identical tests would copy the same steps six times. A data-driven test keeps one test body and moves the cases into a table; the ISTQB glossary describes data-driven testing as a scripting technique in which data files hold the test data and the expected results.

Every major runner supports this. In Jest and Vitest, test.each(rows)("$case", fn) creates one test per row and puts the case value in its title. In pytest, @pytest.mark.parametrize("row", rows) does the same, and pytest.param(row, id=...) names each case. In JUnit 5, @ParameterizedTest combined with @CsvFileSource(resources = "/discount-cases.csv", numLinesToSkip = 1) reads the rows from a CSV file and skips its header line. Playwright Test has no test.each; its documentation creates one test() per row inside a loop, and every title must be unique.

The table below holds inputs and expected results only, and each expected total was worked out by hand from the requirement. The test reads the file and runs each row with a fresh cart from a fixture.

• Give every row a name column. The report then says "expired code failed" instead of "row 5 failed".
• Write values exactly as the system shows them: 200.00, not 200. In CSV, a value that contains a comma, a double quote or a line break should be enclosed in double quotes, and a double quote inside it is written twice (RFC 4180).
• Pitfall, one giant table: a 200-row file with columns for every feature cannot be reviewed, and every change touches it. Keep one table per rule, small enough to read in a minute, and choose the rows with test design techniques such as boundary value analysis instead of piling rows up.
• Pitfall, test logic hidden in data: columns such as click_apply_twice or skip_login turn the table into a program nobody tests. When rows need different steps, they are different tests. The same goes for expected values the test computes with the product's own formula: a defect in the formula then hides on both sides.

data/discount-cases.csv
case,code,cart_total,expected_total,error
valid code,SAVE10,250.00,225.00,
lower-case code,save10,200.00,180.00,
minimum order exactly,SAVE10,200.00,180.00,
just below minimum,SAVE10,199.99,199.99,MIN_ORDER
expired code,OLD5,200.00,200.00,EXPIRED
unknown code,NOPE10,200.00,200.00,NOT_FOUND

test_discounts.py  (pytest: one test body, six reported tests)
import csv
from decimal import Decimal
import pytest

def load_cases(path):
    with open(path, newline="", encoding="utf-8") as f:
        return [pytest.param(row, id=row["case"]) for row in csv.DictReader(f)]

@pytest.mark.parametrize("row", load_cases("data/discount-cases.csv"))
def test_discount_code(cart, row):           # cart: a fixture, fresh per test
    cart.set_total(Decimal(row["cart_total"]))
    result = cart.apply_code(row["code"])
    assert result.total == Decimal(row["expected_total"])
    assert result.error == (row["error"] or None)

Try it: CSV Dataset Generator Try it: CSV to JSON

Frequently asked questions

References

• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Playwright DocumentationMicrosoft (Playwright)Official documentation for Playwright, an end-to-end test framework that drives Chromium, WebKit and Firefox.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011Why flaky tests destroy a suite's value, their common causes (isolation, asynchrony, remote services, time, resource leaks) and quarantine as a response.
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesIETF · 2005The commonly implemented CSV rules: comma separators, CRLF line ends, quoting of fields that contain commas, quotes or line breaks.