Glossary
Fixture
A fixture is a known starting state a test sets up before it runs — seeded data, a logged-in user, a configured environment — so the test has predictable conditions to work from.
Tests need a predictable starting point. A fixture is whatever gets that state ready — the data, the session, the configuration — before the actual checks run.
Examples: a database seeded with three sample orders before an "order list" test runs; a user account created and logged in before a "settings page" test; a mock server configured to return a specific response before an integration test calls it.
Why fixtures matter
Without one, tests either depend on whatever state happens to already exist (fragile, order-dependent) or start from nothing and fail because the precondition they assumed isn't there. A good fixture makes a test self-contained: it sets up exactly what it needs and tears it down afterward, so it doesn't affect other tests.
In practice
Fixture design is a common source of flaky end-to-end tests — see why E2E tests get flaky. Autonomous testing sidesteps most fixture management for exploration (it works with whatever state the app is in), but a dedicated test account with known, resettable data is still the right setup for running a test or a targeted plain-English check.
See also
See how this plays out in practice — start a free run or read the autonomous testing guide.