ReferenceIntermediate4-6 min reference
Test Data Patterns
Flaky, slow, and order-dependent tests are very often a test-data problem, not a test problem. This sheet is a quick map of the patterns for creating and managing test data and their trade-offs. For the team-level strategy see the Test Data Management guide; for generators see the Faker.js and Mockaroo sheets (all linked below).
The patterns
| Pattern | What it is | Best for |
|---|---|---|
| Fixture | Static, predefined dataset | Stable reference data, read-only flows |
| Factory | Code that builds objects with sane defaults + overrides | Most automated tests |
| Builder | Fluent step-by-step object construction | Complex objects with many options |
| Seeding | Load a baseline dataset before a run | Shared/known starting state |
| On-the-fly via API | Create what you need through the app's API | Realistic, end-to-end isolation |
| Anonymized prod copy | Masked production data | Realistic volume/shape (mind privacy) |
Principles that prevent flake
- Isolation: each test creates/owns its data; no shared mutable records.
- Determinism: seed random generators; avoid "today()" — use fixed dates.
- Independence: tests don't depend on each other's leftovers or run order.
- Cleanup: tear down or use fresh namespaces/accounts per run.
- Minimal: only the data the test needs — less to break.
Choosing
- Unit/component → factories/builders.
- Reference/lookup data → fixtures or seeding.
- E2E → create via API for isolation; seed only the immovable baseline.
- Need volume/realism → anonymized prod copy or a generator.
Common mistakes
- One shared account/record mutated by many tests → order-dependent flake.
- Unseeded random data → non-reproducible failures.
- Hard-coded ids/dates that rot over time.
- Reusing production data without masking PII.
- No cleanup → environments fill with stale records.
// Related resources