patterntypescriptModerate
Database seeding strategies: deterministic seeds enable reproducible integration tests
Viewed 0 times
database seedingtest fixturesdeterministic test datatransactional rollbackseed script
Problem
Integration tests insert test data ad-hoc in every test file. Data is inconsistent, tests implicitly depend on insertion order, and debugging a failure requires reasoning about which previous test left the database in which state.
Solution
Create a versioned seed script that inserts a known, minimal dataset before each suite (or before all, with transactional rollback per test). Seeds should use fixed IDs, predictable values, and cover the relationships needed for all tests in the suite.
Why
Deterministic seeds mean any developer can run the suite and see identical results. Fixed IDs eliminate the need to SELECT-then-use in every test. Rolling back transactions after each test is faster than re-seeding and avoids table truncation overhead.
Gotchas
- Seeds with foreign keys must be inserted in dependency order or disable FK constraints during seeding
- Avoid seeding more rows than tests actually need — large seeds slow startup and obscure test intent
- Transaction rollback strategy requires tests to share the same database connection/transaction object
- Seeds for multi-tenant apps must always include a tenant ID to avoid cross-tenant data leakage in tests
Revisions (0)
No revisions yet.