Test Coverage (and Its Limits)

Test coverage measures how much of your code your tests actually run. Picture a house inspector: coverage tells you which rooms got walked through, not whether each room passed inspection. If your tests only ever visit the living room, the coverage report shows the bedrooms were never even entered — a strong hint that bugs could hide there. But high coverage isn't proof of quality: you can walk into every room and still not check whether the lights work.

1. 1A coverage tool watches your code while the tests run and marks each line or branch that executed.
2. 2It divides the parts that ran by the total parts, giving a percentage — say 80% of branches covered.
3. 3The parts never marked are your blind spots: code no test ever exercised.
4. 4You use the report to find untested branches, then add tests aimed straight at them.

Use coverage to find code your tests forgot, especially error branches and rare conditions. Treat it as a flashlight for blind spots, not a grade — chasing 100% for its own sake wastes time on trivial lines while real logic stays weakly checked.

• ⚠Believing 100% coverage means bug-free. Coverage says a line ran, not that you asserted the right thing about it — you can run every line and check nothing meaningful.
• ⚠Gaming the number with tests that execute code but assert nothing. The percentage climbs while the safety net stays full of holes.