Rule-respecting synthetic test data

How it works

Good test data is hard to produce by hand: it has to pass validation, keep foreign keys and cross-field rules consistent, and still look like real usage. The model reads the schema, the validation rules and a description of the scenarios needed, then writes either the data itself or, better for volume, a generator script that produces it. Scenario-driven prompts work well: "a customer with three overdue invoices, one partially paid, in a currency other than the base". The same approach produces deliberately invalid sets for negative testing, each record labelled with the rule it breaks. Keeping the generator script under version control makes the data reproducible.

When to use it

When privacy or legal rules keep real records out of test environments; for scenarios that rarely occur in real data; for load and volume tests that need large, varied datasets; and when setting up a fresh environment whose database starts empty.

Limitations

Synthetic data reflects the rules the model was told about, so it misses the mess real data accumulates over years — legacy formats, half-migrated records, values that should be impossible but exist. Realistic-looking names, addresses and identifiers can accidentally match real people. Data that is varied in obvious ways can still be uniform in the ways that matter, such as distribution of sizes or dates, which hides performance and boundary problems.

What you still own

Deciding which scenarios the data must cover, and checking it against the real data's shape where you're allowed to look.

Cite this