How do you make a schema-derived GraphQL mock return domain-shaped, repeatable values?

## Why type defaults are not enough A schema-derived mock gets you a correctly-shaped response for free, but the values in it are deliberately meaningless. On an insurance claims graph that shows up fast. A `Money` custom scalar has no derivable value at all. A `status` field cycles through enum members with no relation to what the screen under test is meant to show. A `[ClaimDocument!]!` field always returns the same two items, so the empty state and the overflow state are never rendered. The first thing anyone does with a mock is start controlling it. ## The override map The standard mechanism is a map from **type name** to a function that returns a partial object for that type: ``` mocks = { Money: () => "4820.75", ClaimStatus: () => "IN_REVIEW", Claim: () => ({ reference: "CLM-77419", documents: [{}, {}, {}] }), } ``` The semantics that matter are **merge, not replace**. Your `Claim` function names three fields; every other field of `Claim` that the document selects is still filled from its declared type. That is what keeps overrides small: you state only the parts the test cares about, and the mock stays responsible for completeness. A candidate who thinks the override replaces the whole object writes fixtures that break every time a field is added to the type. Overrides also compose downward. `Claim.settlementAmount` has type `Money`, so the `Money` override supplies its value without `Claim` mentioning it at all. This is precisely why the map is keyed by type: one entry for `Money` gives every monetary field in the graph a well-formed value, forever, including fields nobody has written yet. A map keyed by response path - `claim.settlementAmount` - fires for exactly one selection and silently falls back to defaults the moment a fragment moves the field somewhere else. Path-shaped and root-shaped overrides still have a place. For a single test that needs one specific scenario - a denied claim with no settlement - overriding the root `claim` field to return exactly that object is clearer than bending the type-level defaults. The house pattern that scales is a small type-keyed base every test inherits, plus a per-test override layered on top for the scenario under test. ## Controlling list length Collection screens need three shapes: empty, typical, and too many. Mocking layers commonly take the **length of the array you return** as the number of items to generate, filling each element from the item type. So `documents: () => []` gives the empty state, `documents: () => [{}, {}, {}]` gives three, and an array of twenty exercises the overflow. Keep those local to the tests that need them, or the default response grows into something nobody can read. ## Determinism, and why snapshots expose the lack of it A mock that generates a fresh identifier or a random number on every call is fine while you are eyeballing a screen and fatal once an assertion compares a whole payload. The failure looks like this: a snapshot test that has never been edited fails on every run, with a diff showing an id or a list length changing and nothing else. The test is not asserting your component; it is asserting the mocking layer's random source. There are three honest fixes, and they are not equivalent: 1. **Seed the generator.** If the mocking layer draws from a random source you can seed, fix the seed to a constant and the same document produces the same bytes every run. This is the cleanest option because it leaves the rest of the payload realistic. 2. **Pin the values the assertion reads.** Return constants from overrides for those fields. Narrower than seeding, and it survives a change of mocking layer. 3. **Narrow the assertion.** If a snapshot covers values nobody meant to assert, the snapshot is the wrong tool; assert the handful of fields that carry meaning instead. A useful middle path when values must be distinguishable but stable is a **counter per type**: `Claim-1`, `Claim-2`, `ClaimDocument-1`, reset between tests. Constant placeholders make a mis-keyed list look correct, because every row is identical; a counter makes the same bug obvious while still being repeatable. Whichever you choose, the reset has to happen in test setup - a counter that carries across test files reintroduces order-dependence in a new costume. One last rule that is worth stating plainly: never reach for the wall clock inside a mock value function. A `DateTime` derived from `now()` is a non-determinism source that survives seeding, and it produces the specially annoying kind of failure that only reproduces after midnight. ## What none of this changes Overrides make a mock's values look like your domain. They do not make the mock *know* your domain: nothing stops an override map from producing a combination of fields that no real record could hold, and nothing in it is checked against the server. That gap is the subject of the next question.