Test fixture

A fixture is the fixed context a test runs against: the records in the database, the files on disk, the configuration values, the signed-in user, the browser session. It is both the state itself and the code that establishes it beforehand and removes it after. A test with no defined fixture is a test whose outcome depends on whatever the previous one happened to leave behind, which amounts to having no reliable outcome at all.

Fixtures are where a suite quietly decides whether it can be run in parallel, and parallelism is where the total running time gets decided. If every test builds its own data with unique values and clears up after itself, a hundred of them can run at once across separate workers. If they share one seeded database and each assumes it looks a particular way, they have to run in sequence, in a single order, on one machine, and any attempt to speed the suite up produces failures that will be reported as flakiness.

Patterns that hold up as a suite grows

• Create what the test needs inside the test. Explicit setup takes longer to read and is dramatically easier to debug than a shared seed nobody can hold in their head.
• Make the data unique per run. A generated address or an identifier carrying a run token removes an entire class of collision before it appears.
• Set up through the fastest reliable route. Creating an account through an API call rather than by driving the sign-up form keeps a test about the thing it was written to check.
• Tear down even when the test fails, or budget for an environment that gets rebuilt, because a suite that leaks state degrades slightly on every single run.

Most tests described as flaky are fixtures being shared, so the fix is usually data ownership rather than a longer wait.