API Mock Data Generator

Realistic beats random

Random strings pass a schema and prove nothing. Real data has properties that break naive code: names contain apostrophes, hyphens and non-Latin characters; addresses are not always structured; email domains repeat; some fields are legitimately empty. Test data made of "aaaa" and sequential integers passes every test and lets the same bugs reach production. The point of realistic generation is to reproduce the awkwardness of real input before users supply it.

Test the edges deliberately

Include the maximum-length string your schema allows, an empty string where null is also possible, a name with an emoji, a date at a daylight-saving boundary, a negative number where only positives are expected, and text containing quotes and angle brackets. These are where validation, encoding and storage actually fail. A dataset of plausible middle-of-the-range values tests the happy path only.

Referential integrity has to be generated, not hoped for

Seeding orders with random customer IDs produces orders belonging to nobody, and every join returns fewer rows than expected. Generate parents first, retain their identifiers, and draw children from that set. The same applies to enums, foreign keys and any field whose valid values are defined elsewhere.

Distribution matters for performance testing

Real data is skewed. A few customers have thousands of orders and most have one. Uniformly distributed test data makes every query look fast, because it never produces the large result sets, deep pagination and index scans that cause problems in production. If the point is performance, the shape of the distribution matters more than the volume.

Determinism makes failures reproducible

A fixed random seed produces the same dataset every run, so a failing test can be investigated rather than re-rolled. Unseeded generation creates tests that pass ninety-nine times and fail once with no way to reproduce the input, which is worse than no test.

Never use production data as test data

Copying a production database into staging is the most common route to a personal data breach that nobody intended. Under GDPR and similar regimes it is processing without a lawful basis, and staging environments are consistently less protected than production. Generated data carries none of that exposure. Where production-shaped data is genuinely needed, the requirement is proper anonymisation, and note that removing names is not anonymisation when the remaining fields still identify people.