The Case For Input Coverage
This post is part of the Input Coverage > Code Coverage series.
Tests execute lines. Users supply inputs. These are different concerns.
Code coverage answers: which branches ran? Input coverage answers: which values did we try?
High code coverage can hide low input coverage. A single happy-path value can cover many lines. Bugs live on weird values and bad assumptions.
Property tests help. They expand the input set. Still, generators are biased. They reflect what you think is reasonable. Attackers and random machines disagree.
Coverage-guided fuzzers mutate inputs to hit new code paths. They do not respect your assumptions. That is useful. It finds bugs your tests proved away.
This series shows minimal, reproducible setups. Little ceremony. Real bugs. Small fixes.