Hand-built test fixtures age badly: a new required field means editing forty setup blocks, and tests start failing for reasons unrelated to what they test. The factory pattern — fixtures created through functions with sensible defaults — has become the default approach in 2026, with fakes handling the services those fixtures depend on.

Build data at the point of use

Factories that create just the records a test needs, with defaults overridden per case, produce tests whose intent is visible in the setup. Dumped fixture files hide which fields the test actually depends on.

Fakes for boundaries

Replace external services with fakes at the integration boundary: deterministic responses, no network, no cost. The tests become faster and hermetic, and failures point at your logic rather than third-party availability.

Testing illustration
Illustration: Testing — photo via Unsplash

Isolate per test

Every test creating its own data removes ordering dependencies, which eliminates an entire class of flakiness. Shared state between tests is the root of most intermittence, and independent fixtures cut it at the source.

Designing factories that stay maintainable

The rules that keep factories healthy: every factory has defaults for all fields with overrides only for what the test cares about; state variants (published, archived, locked) are named functions rather than inline parameter soup; and related records are created through the same factories instead of raw inserts, preserving referential intent. The test then reads as its scenario — a published article with two drafts — rather than as a database insert list.

Fakes over mocks for services

External services in tests work best as fakes: in-memory implementations of the same interface with scriptable behavior (a payment fake that can be told to decline, a clock that can be advanced). Fakes survive refactoring better than interaction mocks, which break whenever internal call patterns change even when behavior is preserved. Reserve strict mocks for contracts where the exact call matters — payments and side-effect boundaries — and fake everything else.

Testing illustration
Illustration: Testing — photo via Unsplash

Key takeaways

  • Factories: full defaults, named states, related records via factories.
  • Prefer scriptable fakes over interaction mocks for services.
  • Tests should read as scenarios, not as insert lists.

Final thoughts

Fixture quality determines how much a test suite costs to maintain as the product evolves, and teams that invest in factories and fakes find their tests surviving refactors that previously broke everything.

Sources & further reading