How do you manage test data?

Direct answer

What a strong answer covers

How it works

Good test data is minimal, deterministic, and owned by the test that needs it. It is created through the same APIs or factories the product uses, so it stays valid as the schema changes, with defaults for everything irrelevant and explicit overrides for what the test is about. Each test or worker gets its own namespace, such as a unique tenant or a prefixed identifier, so parallel runs and reruns do not collide. Real personal data never enters test environments; production-shaped samples are synthesised or masked. Clocks, random seeds, and identities are controlled so results repeat, and cleanup is either automatic through disposable databases or unnecessary because data is isolated.

Example

A test that checks overdue invoice reminders calls createCustomer and createInvoice factories with an explicit due date, runs against a database schema created per worker, and freezes the clock at a date three days past due. A masked snapshot of production, with names, emails, and card data replaced, seeds the performance environment monthly. Nobody copies production dumps to laptops.

Common mistakes

• Sharing one seeded database between tests that modify it.
• Hard-coding IDs that only exist in one environment.
• Copying real customer data into test systems.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.