Test fixture
In software testing, a test fixture is the fixed, known state a test needs before it runs: the database rows, the files, the configuration and the objects that have to exist for the test's steps to mean anything. The fixture is set up before the test, torn down after it, and identical every time, so that a failure points at the code under test rather than at the starting conditions.
The longer version
A test is a comparison between what the code did and what it should have done, and the comparison is only fair if the starting state is the same on every run. The fixture is that starting state. For a unit test it is a constructed object with known fields; for an integration test it is a seeded database, a temporary directory and an environment variable; for a browser test it is a signed-in account with a specific record open. Test frameworks give it a lifecycle: a setup step that builds it, the test body that uses it, and a teardown that removes it so the next test starts clean.
The word has a hardware sense, a jig that holds a physical part in place while it is machined or inspected, and that sense fills part of the search results; what follows is the software fixture. Within software, a fixture is distinguished from test data by scope: test data is the values fed to the code, the fixture is the environment those values are fed into, and the fixture usually contains test data. It is distinguished from a mock or a stub by being real. A fixture is an actual database with actual rows; a mock is a stand-in for a collaborator that is deliberately absent during the test.
A fixture shared across a whole suite for speed, and mutated by one test, makes a later test fail only when it runs after the first one. Those failures reproduce in the full run and vanish in isolation, and they are read as flakiness for weeks before somebody notices the shared row. A fixture that has drifted from production fails more slowly: a seeded user with every permission, a catalogue with no discontinued products, and the tests pass against a world with none of the awkward records real data contains.
Common questions
What is the difference between a test fixture and test data?
Test data is the set of values a test feeds to the code: the inputs, the records, the files. A test fixture is the known state the test runs inside, which includes that data plus the configuration, the connections and the objects that have to exist first. The fixture is set up and torn down; the data is what gets used within it.
Is a test fixture the same as a mock?
No. A fixture is real state, such as a seeded database or a constructed object, that the test uses directly. A mock is a stand-in for a collaborator the test deliberately does not use for real, such as a payment gateway. A fixture can contain mocks, but a mock on its own is not a fixture.
Should test fixtures be shared between tests?
Sharing saves setup time and costs isolation. A fixture that one test mutates makes a later test depend on running order, and those failures appear in the full run and vanish when the failing test is run alone. Sharing a read-only fixture is safe; sharing one that tests write to is the usual cause of order-dependent failures.
What is setup and teardown in a test fixture?
Setup is the step that builds the fixture before the test body runs: seeding the rows, creating the temporary directory, constructing the object with known fields. Teardown is the step that removes it afterwards so the next test starts clean. Test frameworks run both automatically around each test or each suite, and a teardown that is skipped on failure is the usual source of state leaking between runs.
What should a test fixture contain?
Only the state the test's steps depend on, and nothing that is there for convenience. A sign-in test needs an account with a known password; it does not need a catalogue, an order history or every permission flag set. A fixture that carries more than the test uses is slower to build, harder to read, and hides the case where a missing record is what the code cannot handle.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.