The screenshot always looks fine
A table with three rows of test1, test2, test3 looks calm. Columns line up. Nothing wraps. The spacing reads as deliberate. You move on, because the screen in front of you says the work is done.
Then real data arrives, and it is nothing like the fixture. A company name is sixty characters. A price is negative because it is a refund. A user has no last name at all. Half the notes field is empty. The layout that looked deliberate was only ever agreeing with the data you happened to type.
Nothing was overlooked out of carelessness. The fixture simply never asked the question.
What placeholder data hides
Each convenient shortcut removes a specific class of bug from view:
| The fixture | What it hides |
|---|---|
| test1, test2, asdf | Every layout question. Four characters fit anywhere, so nothing wraps, truncates, or pushes a column out of alignment. |
| John Doe, Jane Doe | Long names, single names, hyphenated names, and diacritics. A row that survives “Doe” can still break on “Şeyma Kaya-Öztürk”. |
| Ten identical rows | Sorting, grouping, and pagination. Identical values make a broken sort look correct and an off-by-one page boundary invisible. |
| lorem ipsum | Where text actually ends. Latin filler has an even rhythm and no long words, so it never reveals the paragraph that overflows its card. |
| $100.00 everywhere | Zero, negatives, refunds, and thousands separators — plus the decimal comma that a German or Turkish locale expects. |
| Every field filled in | The empty state. Most production rows have at least one null, and that is the row that renders “undefined” in front of a customer. |
None of these are exotic inputs. They are the ordinary contents of a production table — which is why they are the ones that reach a user first.
Why we reach for the placeholder anyway
Because good fixtures are a detour. You are mid-thought, the view needs something to render, and typing asdf costs one second while writing a seed script costs twenty minutes. The shortcut is not laziness; it is the only option that does not interrupt the thing you were actually doing.
So the question is not whether developers know better. It is whether realistic data can be made as cheap as unrealistic data. If it costs the same second, nobody types asdf again.
Making the honest fixture the cheap one
Cedra starts from the schema you already have. Paste a JSON sample, a JSON Schema, a SQL CREATE TABLE, or a TypeScript type; it reads the field names and types, picks a generator for each field, and tells you how confident it is about the match — so the fields it guessed badly are the ones you look at.
- Names that stress the layout. Real first, last, and full names — including the long ones and the ones with diacritics that break a fixed-width column.
- Locale-aware values. Generate in English (US), Türkçe, or Deutsch. Names, addresses, phone numbers, and postal codes follow the locale instead of being US shapes with translated labels.
- Enough rows to sort. Batches rather than a handful of rows, so pagination, ordering, and grouping have something to be wrong about.
- Straight into the app. Copy the batch, export it, or inject a single value into whatever field is focused — the reason it stays cheaper than a detour.
What you can do today
Three habits, tool or no tool:
- Keep a hostile row. One record with the longest plausible name, an empty optional field, a zero, and a negative number. If the screen survives that row, it will survive most Tuesdays.
- Generate more rows than feel necessary. Bugs in sorting, pagination, and grouping only appear once the list is longer than one screen.
- Test in a second locale. A decimal comma, a longer date format, and a non-ASCII name catch a surprising share of formatting assumptions in one pass.
The local alternative
Fixtures that argue back.
Cedra is a small macOS mock data generator built for fixtures, payloads, demos, and UI-ready test content — generated locally, from the schema you already have. It is free for everyday batches, and a one-time licence lifts the limits.