Book 10 · Testing & QualityPage 31 of 36

Test Fixture

Updated September 30, 20262 min read

In short

A test fixture is the known state a test needs before it runs, such as sample data or a configured object, plus the code that sets it up and tears it down.

What is a test fixture?

A test fixture is everything a test needs to be in place before it can run, prepared in exactly the same way every time. It might be a few sample records in a database, a temporary folder with input files, a configured object, or a running test server. Because every run starts from the same known baseline, the test's result depends only on the code under test.

Most frameworks split a fixture's life into setup, which creates the state, and teardown, which cleans it up even when the test fails. Some frameworks use methods such as setUp and tearDown or hooks such as beforeEach and afterEach, while pytest uses fixture functions that are passed into any test that names them as a parameter. Fixtures can be created for each test, for each file, or once for the whole run: sharing an expensive fixture such as a database container saves time, but shared data that tests change can make them depend on each other and become flaky.

A fixture is like a theater stage set that is arranged identically before every performance, so the actors can rely on each prop being in the same place. Fixtures appear in unit tests (a prepared object), integration tests (a seeded database), and end-to-end tests (a logged-in user account). The word is also used for static sample data files, such as JSON or SQL files full of test records.

Test fixtures are often confused with mocks. A fixture prepares the world the test runs in, while a mock is a fake stand-in for a dependency that the code under test calls. A fixture can create and hand over a mock, but many fixtures are real things, such as an in-memory database or a temporary file.

Key takeaways

A fixture is the known starting state that a test relies on.
Setup creates the state, and teardown cleans it up afterward.
Fixtures can be scoped per test, per file, or per test run.
Shared fixtures that tests modify are a common cause of flaky tests.
A fixture sets up the environment; a mock replaces a dependency.

Example

A pytest fixture with setup and teardownpython

import sqlite3
import pytest

@pytest.fixture
def db():
    # Setup: a fresh in-memory database with known data for every test
    conn = sqlite3.connect(":memory:")
    conn.execute("CREATE TABLE users (name TEXT)")
    conn.execute("INSERT INTO users VALUES ('Ada'), ('Grace')")
    yield conn  # the test runs here
    conn.close()  # Teardown: runs even if the test fails

def test_counts_users(db):
    assert db.execute("SELECT COUNT(*) FROM users").fetchone() == (2,)

Readers ask

What is the difference between a fixture and a mock?

A fixture sets up the state or resources a test needs, such as data or a temporary file. A mock is a fake version of a dependency that the code calls, and it can also record how it was used.

What are setup and teardown in testing?

Setup is the code that prepares a test's fixture before it runs, and teardown is the code that removes or resets it afterward. Together they keep every test independent of the ones that ran before it.