Test pins a state nothing produces

What goes wrong

A test builds its input by hand and asserts on it, but no code path can ever create that state. The assertion then holds regardless of the behaviour it names, and the reader relies on the green result as evidence that the inputs real users generate are handled.

Example

A test builds a record with one field left empty and asserts the handler copes, though every writer of that record always fills the field in.

Not to be confused with

Not Fixture never creates the triggering condition, where the state is reachable and the setup simply fails to build it; here the state itself cannot exist outside the test.

Discovered by

@sks24git GitHub

Field notes · 8

@sks24git2026-11-04beat 1 review round

A query gained a new boolean column, but hand-built fake rows in other tests never set it. The missing field reads as false, so those tests pass while exercising a state real data never produces.

Update every hand-built fixture when a row's shape changes. A missing field reads as false and quietly turns the test into a different case.

@sks24git2026-11-04

A test fixture swaps a fake region code for a real one, but picks a whole-region heading row, not a district. It passes only while the check stays loose, and turns red again the day the check gets strict.

Pick fixture values the strict rule would accept. A value that passes only a loose check breaks again when the check gets tight.

@sks24git2026-10-30beat 1 review round

A plan check pinned the old, unscoped form of a query while every caller moved to a scoped one. A plan regression in the shape production actually runs would pass every test and time out live.

Guard the shape production runs. When callers move to a new form of a query, move its plan check with them.

@sks24git2026-09-12beat 1 review round

A narrowing on a hand-run repair was justified by a case the code cannot produce, and its test inserted that impossible row to prove it. Both read as considered; neither guarded anything.

Justify a guard by reachability, not by intent. Ask which rows the query can actually see.
A fixture the code cannot produce pins the clause, not the scenario.

@sks24git2026-09-12

A slow query was cleared by an a database command that put a literal where the code passes a column. That makes the subquery uncorrelated, so it hashes, so it looks cheap - and the real shape ran per row.

Measure the query the code runs, with its real correlations. A literal in place of a column is a different plan.
A correlated subquery cannot be hashed.

@sks24git2026-09-12beat 1 review round

A blind test was fixed by pointing it at a shape the producer cannot emit. The guard it names still decides nothing on real data, and the suite now looks covered exactly where it is not.

When you fix a blind test, check the new input is producible. A pin on an unreachable state is coverage theatre.
Ask who writes this state, not whether the type admits it.

@sks24git2026-09-10beat 5 review rounds

A fixture documented as a retired debt lot was inserted already at zero with the grant left on it. The test then emitted the very imbalance it exists to prove absent, and asserted only the keys it expected.

Assert the absence you claim over the whole result, not over the keys you expected. Otherwise the proof carries the defect.
A fixture's doc is not its shape — read the insert.

@sks24git2026-09-10

A flag-off arm was simulated by handing the service a null repository, which is a build with no persistence rather than the feature switched off. A sibling test pinned the opposite outcome for that same seeded state.

Reach OFF through the production path. Nulling a dependency fakes a deployment that cannot exist, and its outcome is not the one users get.