Mock Castle

trigger

"21 vi.mock() calls, 65 lines of mock setup, 45 lines of assertions. Testing a 4-line predicate function."

what it is

Mock scaffolding consumes more lines, more cognitive load, and more maintenance surface than the actual assertions. The test primarily verifies mock wiring, not product behavior. The mocks exist solely to prevent import crashes from side-effect-heavy modules, not to control behavior. A test file with a 4:1 mock-to-assertion ratio provides less regression confidence than its line count implies because the mocks are where the bugs will hide — stale mock shapes, implementations that diverge from real module behavior over time.

what it signals

Count mock declarations vs test assertions per file. If mock setup exceeds 3x assertion code, the test is a castle built on sand. The LLM creates the mocks because it must, then writes the tests it came for, never questioning whether the architecture makes the code untestable without them.

instead

Extract pure functions into a separate module with no side-effect imports. Test them without mocking the universe. Reserve mock-heavy tests for genuine integration scenarios.

refs

• wake:tests/unit/bout-engine-helpers.test.ts — 21 vi.mock() for 2 pure functions
• wake:tests/unit/bout-engine-behavior.test.ts — identical scaffold duplicated