Sourcing Fixtures

A **fixture**, in this sense, is the data that must already exist before a test runs — the records the behaviour under test reads, updates or reports on. Deciding where that data comes from is a design choice, and interviewers ask about it early because the three available answers trade the same three things against each other: readability, realism and privacy. ### Hand-built minimal fixtures The test constructs the records it needs, and nothing else. Two teachers, one room, three timetable slots. The properties that matter are that the data is **visible** — a reader of the test can see exactly what state produced the result — and that it is **owned** by the case, so nobody else's edit changes it. A failure is diagnosable because the input is three lines above the assertion rather than in a file someone loaded years ago. The cost is that hand-built data is an act of imagination. It contains what the author thought was possible. A field that is optional in the schema but empty in ninety per cent of real rows will usually be populated in a hand-built fixture, and the code path for the empty case never runs in the suite. ### Generated records A generator produces records from rules: a name pattern, a value range, a distribution, a count. This is how you get a thousand of something without typing a thousand of something, and it is the right tool for size-sensitive behaviour (a report that must page, a scheduler that must stay inside a time budget), for sweeping a parameter space, and for filling in the many fields a case never asserts on. The limitation is structural rather than accidental: a generator emits data the model permits. It writes the schema as the team currently understands it. The row inserted four years ago by a since-deleted import path, whose end date precedes its start date, is not in the generator's grammar. How much realism a generator can be pushed to reach is genuinely contested — teams that invest in distribution-shaped generation report catching far more than teams that do not — but the class of defect it structurally cannot produce is the record that violates today's invariants and exists anyway. ### Production-derived extracts Here records are copied out of the live store and transformed before they land anywhere a test can reach: **subset** (take a referentially consistent slice rather than everything), **masked** (personal values removed or replaced), and often **pinned** to a fixed point so the data does not shift under the suite. This is the only source that carries real skew — the one account with four hundred children where every other has two, the encoding oddities, the historical rows. The cost is that the moment real personal data lands in a test environment, it brings its obligations with it into a place with weaker access control, more copies, and more people. That is why extracts are transformed rather than restored, and why a masking step that only half-ran must be treated as no masking at all. ### A worked comparison A school timetable planner, maintained by an 11-person team. Production holds 4,213 students, 187 teachers, 1,046 courses and 61,214 timetable slots. - *Clash detection*: two teachers, three slots, one deliberate overlap. Hand-built. The whole fixture fits in one screen and the assertion names the clash. - *Whole-term rebuild inside a time budget*: 60,000 generated slots across generated courses. Nobody reads them; the shape and the count are the point. - *A defect only real data reproduces*: one teacher is registered at two schools and appears twice in the staff list with the same identifier. No hand-built fixture invented that, and no generator was told it was possible. A masked extract of the staff and enrolment tables reproduces it on the first run. ### How to answer the choice Default to hand-built, because readable data is a permanent asset and invented data is a one-time cost. Generate when the case is about size, spread or a sweep rather than about a specific record. Reach for an extract when you need shapes you cannot invent — and then take the smallest referentially valid slice you can, transform the personal fields, and be able to rebuild the whole extract from the pipeline rather than treating it as a precious artefact. The three are not exclusive. A common shape is a masked extract as the background the environment starts from, with each case still creating the specific records it asserts on, so the assertions never depend on data the case did not put there.