Skip to content
SDETRole
SDETRole

Glossary · UI automation

Test fixture

Also called: test fixtures, fixtures

Definition

The fixed setup a test needs before it runs, such as a browser page, a seeded user or a database, plus the teardown that cleans it up afterwards.

A test fixture is everything a test depends on that is not the behaviour under test: the objects, data, connections and environment that must be in a known state before the first step runs. A good fixture sets that state up the same way every time and tears it down afterwards, so each test starts clean. The word is also used more loosely for static test data files, such as the JSON files Cypress loads with cy.fixture().

Example (Playwright)

Playwright has fixtures as a first-class feature. Built-in ones like page and request are injected by name, and you add your own with test.extend:

import { test as base, expect } from '@playwright/test';
import { TodoPage } from './todo-page';

type Fixtures = { todoPage: TodoPage };

export const test = base.extend<Fixtures>({
  todoPage: async ({ page }, use) => {
    const todoPage = new TodoPage(page);   // setup
    await todoPage.goto();
    await use(todoPage);                   // the test runs here
    await todoPage.removeAll();            // teardown
  },
});

test('adds an item', async ({ todoPage }) => {
  await todoPage.add('Write the glossary');
  await expect(todoPage.items).toHaveCount(1);
});

Fixtures are created only when a test asks for them, can depend on other fixtures, and can be scoped per test (default) or per worker with { scope: 'worker' } for expensive resources.

Example (JUnit 5)

In xUnit-style frameworks the fixture lives in lifecycle methods:

class CartServiceTest {
    private CartService cart;

    @BeforeEach
    void setUp() {
        cart = new CartService(new InMemoryCartRepository());
    }

    @AfterEach
    void tearDown() {
        cart.clear();
    }

    @Test
    void emptyCartHasZeroTotal() {
        assertEquals(0, cart.total());
    }
}

@BeforeAll and @AfterAll run once per class and must be static by default.

Common mistakes

  • Sharing mutable fixture state between tests. A worker-scoped user that tests modify will cause order-dependent failures.
  • Skipping teardown when a test fails. Put cleanup in the fixture (after use) or in @AfterEach, not at the end of the test body.
  • One giant fixture for everything. Small, composable fixtures make it obvious what each test depends on.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →