Q31 of 38 · Test design
How do you design test data for a database-driven feature?
Short answer
Short answer: Create test data as close to the test as possible using factory functions or builders, never depend on pre-existing database state, and use representative data that exercises the real schema constraints rather than placeholder strings.
Detail
Static shared fixtures are the most common anti-pattern: a single JSON file or SQL seed that everyone's tests depend on. Any test that modifies data corrupts other tests' assumptions, creating order-dependent failures that are hard to diagnose.
The factory pattern solves this: each test creates exactly the data it needs, verifies its outcome, then cleans up (or rolls back). In practice: a createUser(overrides) function creates a valid user with sensible defaults, and each test overrides only the fields relevant to its scenario.
Design test data to exercise real constraints:
- Use data that hits actual length limits (not just "test123")
- Include Unicode characters, special characters, and numbers in name fields
- Use realistic foreign key relationships rather than placeholder IDs
- For financial data, test with values that expose floating-point precision issues
For large-volume data (pagination, performance), use a dedicated seed script and document that tests in this area require the larger dataset.