54. Fuzzing the source input (pocket version)

TL;DR (5 lines)

Tests are evidence of a specific claim.
Different layers prove different things.
A compact flow is enough to teach testing structure.
Invalid paths deserve explicit fixtures.
The chapter should teach proof design, not ritual.

Concrete Problem

Testing chapters often become lists of test names instead of explanations of what evidence each layer should provide.

Coherent example

space demo/tests

proc classify_score(x: int) -> int {
  if x < 0 { give 11 }
  if x > 100 { give 12 }
  give 0
}

Global explanation

Testing pages should explain what each test proves. A useful chapter distinguishes local invariants, end-to-end scenarios, regression proof, and failure-focused fixtures without collapsing them into one vague category.

Short exercise

Take the example and write one invariant it needs, one scenario it needs, and one invalid-path check it needs.

Next best action

Keep the example small, reproduce it locally, then continue to the full chapter if you need the broader context.