Test data management
Test data management is the discipline of producing, maintaining, and isolating the data used in tests — fixtures, factories, seeded databases, anonymised production snapshots. Poor test data management is one of the largest sources of test-suite slowness, flakiness, and false confidence.
The trade-off space is wide: hand-written fixtures are clear but tedious to maintain; factories (Factory Bot, Faker, Stride's typed factory) produce data programmatically but can mask coupling between tests; anonymised production snapshots are realistic but expensive to refresh. The cardinal rules: each test owns its data (no shared state across tests), data is realistic but minimal (no kitchen-sink fixtures that obscure what the test cares about), and the seeding mechanism is fast (database snapshot restore beats per-test inserts for integration suites). Modern test runners (vitest, Jest) include parallel execution that exposes test-data-coupling bugs quickly.
Related terms
- Test fixture
A test fixture is the prepared state required to run a test — input data, mocked dependencies, configured environment, seeded database rows.
- Test isolation
Test isolation is the property that each test runs independently — no shared state, no execution-order dependency, no side effects bleeding to the next test.
- Integration test
An integration test verifies that multiple components work together correctly — a service hitting a real database, two microservices communicating, a frontend talking to a real API.