Mock Data That Actually Exercises Your UI (Not Just Fills It)

Mock data is the placeholder you ship to the frontend while the backend is still being built. The quality of that placeholder decides which bugs you find before the backend exists and which you find after launch. Most mock data is bad in a specific, predictable way: it is too uniform. Ten rows with the same name and a different id fill the page and exercise almost none of the rendering code.

Why uniform mock data hides bugs

A row with a short name, a short email, and a present avatar renders fine. So does a row with a long name, a missing avatar, and a null field. The bugs live at the boundary, where the name wraps, where the avatar is missing, where the field is null instead of an empty string, where the date is in an unexpected format. Uniform mock data never reaches the boundary, so the formatting code that handles the boundary is never run until production.

The fix is not more rows. The fix is varied rows. A dataset of fifty rows is plenty if those rows include a long name, a name with non-Latin characters, a missing optional field, a zero where a number is expected, and a date in more than one format. If every row looks like the first row with a different id, the dataset tests nothing.

Field inference is the shortcut

Writing a mock schema by hand is tedious, which is why people skip it and paste the same row ten times. Field inference flips this: you give the tool one sample JSON object, and it infers what each field is from the field name and value. A field called email gets generated as a plausible email. A field called avatar gets a placeholder image URL. A field called createdAt gets a timestamp within a range you control. A field called total gets a number with the right scale.

The point of inference is not that it is perfectly accurate. It is that it produces varied, plausible values for free, so the dataset exercises the UI without you writing a generator. The inference is right most of the time for fields with conventional names. For fields with unusual names, you override the inferred type, but you do that for a few fields, not all of them.

The edge cases that actually break formatting

Name fields break layouts when they are long, when they contain spaces in unexpected places, and when they contain non-Latin scripts. A mock dataset should include at least one of each. The long name tests whether your layout truncates or wraps. The non-Latin name tests whether your font stack and your string handling are correct.

Date fields break when the format varies. If your formatting code assumes ISO 8601 and the mock data is all ISO 8601, the code works. When production sends a timestamp in seconds instead of milliseconds, the code renders a date in 1971. Include both formats in the mock data, or at least one row with an unexpected format, and the bug shows up in development instead of in a user's ticket.

Number fields break at the edges: zero, negative, very large, and numbers with more decimal places than your display code expects. A mock dataset where every total is between 100 and 500 tests none of these. Include a zero, a negative, and a large number, and the rounding and alignment code gets exercised.

Missing fields and null versus empty

Real API responses omit fields and return null. Your rendering code has to handle both, and they are different. A missing field is undefined in JavaScript. A null field is null. An empty string is "". Each can break a different code path, and code that handles one often does not handle the others.

Good mock data includes rows with missing fields, rows with null fields, and rows with empty strings, so the ?. optional chaining and the ?? nullish coalescing and the || fallback all get tested. If every row has every field present and non-null, the defensive code is never run, and the first null from production throws an error.

How much mock data is enough

Fifty rows is usually enough. One hundred is plenty. One thousand is only useful if you are testing pagination or virtualization. The mistake is generating ten thousand rows of uniform data, which tests scroll performance and nothing else.

Start with a sample object, generate fifty varied rows, and then manually add three or four specific edge cases the inference did not produce: a long name, a missing required field, a date in the wrong format. The manually added rows are the ones that find the bugs. The generated rows are the ones that make the page look populated.

Keep the mock data with the test

Mock data that lives in a shared file and is reused across every test becomes invisible. No one looks at it, no one updates it, and it slowly drifts from the shape of the real API. When the API changes, the mock data does not, and the tests pass against a shape that no longer exists.

Keep mock data close to the test that uses it, generate it fresh from a current sample when the API changes, and treat the sample JSON as the source of truth. The Mock tool on this site generates from a sample, so when the API shape changes, you paste the new sample and regenerate, instead of hand-editing a stale fixture.