Your team's Kotest property tests each declare their own generators inline, and the same domain objects are generated five slightly different ways across the suite. How would you organise generators for a real domain model, and what conventions would you set?

## Why generator sprawl matters In a property suite the generator *is* the specification of the input space. When five specs each build an `Order` slightly differently, you have five undocumented, contradictory specifications, and the resulting green build tells you less than it appears to. Worse, the drift is invisible: nothing fails when one spec's generator forgets that quantities are positive — the tests just stop covering the interesting cases, or start reporting counterexamples that could never occur in production. ## The structure **One arb per type, composed upward.** Mirror the domain model: ```kotlin object Gen { val money = Arb.long(0..1_000_000).map(::Money) val sku = Arb.stringPattern-free() // build from primitives you control val line = Arb.bind(sku, Arb.int(1..10), money) { s, q, m -> OrderLine(s, q, m) } val order = arbitrary { val lines = Arb.list(line, 1..5).bind() Order(id = Arb.uuid().bind().toString(), lines = lines, total = lines.sumOf { it.amount }) } } ``` Each level is small, named, and reusable. `Arb.bind` handles independent fields; the `arbitrary { }` builder handles derived ones. Aggregates get built from the parts, exactly like the production model. **Where it lives.** A dedicated test-fixtures source set or module, so both unit and integration specs can use the same generators without one test module depending on another's test code. The key property is that there is exactly one definition to change when the domain changes. ## The conventions worth writing down ### 1. Legal by construction, not by filtering Every `filter` in a generator is a place where the constraint was expressed too late — it burns draws, skews the distribution and can stall when the acceptance rate is low. Push the constraint into the generator: `Arb.int(1..10)` rather than `Arb.int().filter { it in 1..10 }`; derive the dependent field in `arbitrary { }` rather than generating two and rejecting the mismatches. Reserve `filter` for cheap, rare exclusions. ### 2. Parameterise instead of forking When a test needs a narrower input space, the wrong move is a private copy of the generator. Two right moves: expose the generator as a function with defaults (`fun order(region: Arb<Region> = Gen.region): Arb<Order>`), or compose at the call site (`Gen.order.map { it.copy(status = PAID) }`, `Gen.order.filter { … }` only if rare). Both keep one source of truth for the shape. ### 3. Purity is non-negotiable Generators must draw only from Kotest's random source. A `Random.nextInt()`, a `Instant.now()` or a database lookup inside a generator destroys seed-based replay — the printed seed will not reproduce the failure — and can also fire repeatedly during shrinking, when the property body is re-run with candidate values. Make this an explicit review rule; it is the single most common cause of "the CI failure won't reproduce locally". ### 4. Model the real distribution Uniform is not realistic. If production traffic is 95% well-formed, weight the generator with `Arb.choose(19 to valid, 1 to malformed)` rather than a 50/50 `Arb.choice`, so the iteration budget goes where the logic is deep. Conversely, if a rare shape is where the bugs are, deliberately over-weight it and say so in a comment. Distribution choices are design decisions and deserve a sentence of rationale. ### 5. Invest in shrinking where counterexamples are read For the two or three aggregates that dominate your failure output, it is worth supplying a `Shrinker` or restructuring the composition so component shrinkers apply (favouring `map`/`bind` over hand assembly). For the long tail, coarse counterexamples are fine. This is a cost/benefit call, not a blanket rule. ### 6. Review generators like production code A subtly wrong generator produces a green, meaningless suite — the failure mode nobody notices. Put generators in the same review lane as the code they test: does the range match the domain, does the distribution match reality, is it pure, does it still shrink? ## Trade-offs to acknowledge - **Central library vs. local clarity.** A shared generator is one indirection away from the test that uses it; keep them small, named after the domain type, and grouped so the jump is cheap. - **Constrained vs. adversarial.** Constraining generators to the legal domain is right for domain logic, but for parsers and boundary code you *want* the illegal values. Keep both: a `valid` and a `hostile` generator per boundary type, weighted for the test at hand. - **Reflective shortcuts.** Reflective generation is fine for wire DTOs in codec round-trips; it is wrong for validated domain types, and mixing the two policies without saying which applies where is how illegal values sneak in. ## The signal in an interview This question has no single right answer; it checks whether you treat the generator as part of the specification, whether you have opinions about purity and distribution, and whether you can name the failure modes — drift, rejection sampling, non-reproducible seeds, vacuous green suites.