A bulk generator filled a test dataset with realistic records: which rows will it essentially never produce, and why plant those by hand?

A manufactured dataset has two jobs at once, and a bulk generator only does one of them. ## Realism and rarity pull in opposite directions The first job is to be **plausible**: volumes, distributions and combinations close enough to the live store that a paging screen, a report and a query plan all behave roughly the way they will behave for real. The second job is to **contain the situations the code has branches for**. A generator fitted to real proportions serves the first well and the second badly, for a reason no amount of tuning removes: it emits rows in proportion to how often they occur. If one customer in fifty thousand has no recorded surname, a hundred thousand generated rows contain about two of them, and "about two" means some builds contain none. If one order in a million sits exactly on the agreed maximum amount, no realistic dataset of a size a test suite can load will reliably contain one. The rows that break code are, almost by definition, the rows a faithful distribution barely produces. So the dataset splits into two parts governed by different rules. **Background volume** comes from the generator and exists to make the shape realistic. **Planted rows** are authored one at a time, each because some branch of the product exists to handle it. ## What earns a planted row The catalogue is short, and it comes from reading the code rather than from imagination. Walk the read and write paths and ask what each one special-cases. | Situation to plant | Why generation misses it | What it breaks | |---|---|---| | An optional field left empty | optional fields are usually filled in | a display or export that assumes a value | | A value exactly on an agreed limit, and one past it | limits sit in the far tail | a comparison written with the wrong strictness | | A name written right to left | the fitted sample is regional | layout, truncation, ordering of names | | A field at its maximum stored length | lengths cluster well below the cap | overflow, silent truncation, broken alignment | | A record already past its expiry date | generated dates cluster near now | renewal logic, filters that assume validity | | A child row whose parent record is gone | generation builds parents first | joins, cascade handling, reported totals | | A row flagged deleted but still stored | deletion is rare and recent | listings that forget to filter, counts | | A state the running product can no longer create | today's writers cannot emit it | read paths older than the writers | Two of those deserve a note. Text written right to left is not an exotic curiosity — it exercises the entire display stack, and it is the single cheapest planted row most teams are missing. And a child row whose parent is gone is a real state in most stores that have ever had a partial cleanup, however firmly the schema claims otherwise. ## How to plant 1. **One row per situation, authored explicitly.** Not "make the generator emit more of these": a raised rate is still a random draw, and it distorts the very proportions the background volume exists to provide. 2. **Fixed and named.** The row is referenced by a name you chose, so a test asks for the situation rather than for a number somebody read off a screen. 3. **Loaded alongside the volume, not instead of it.** Planted rows sitting in a miniature dataset of their own only prove the code works on ten rows; the point is that they are present while a realistic amount of everything else is present too. 4. **Justified by a branch.** A planted row earns its place because some code path handles it. A row that is merely strange adds maintenance and proves nothing when it breaks. ## Why not just tune the generator The tempting shortcut is to raise the frequency of the rare shapes until they show up naturally. It fails on both jobs. The dataset stops being realistic, so anything that reads an aggregate, depends on selectivity or pages through results now sees a population that does not exist. And it still gives no guarantee about the *specific* row: raising a rate to one in a hundred means a build can still miss it, and whichever row does arrive carries whatever other values the draw produced, so a test cannot assert against it precisely. The opposite failure is a team that plants nothing and simply generates a very large dataset, on the theory that enough rows contain everything. Enough rows contain everything that is merely *uncommon*. They contain nothing the distribution assigns essentially zero probability — which is exactly where the impossible-looking states that do reach production live. ## The cost side Planted rows are permanent, and each one is something a future reader must understand. A set that only grows becomes a museum. Keep the justification next to the row — which branch it exercises — so the set can be pruned when that branch disappears, and review the planted set like code rather than letting it accumulate like sediment.