Test Coverage and Its Limits

Test coverage measures what fraction of your codebase's lines, branches, or statements get executed at least once when the test suite runs. It's produced automatically by instrumenting the code and recording which lines fire during a test run, then reporting a percentage like "87% line coverage." Teams often set a minimum coverage threshold — say, 80% — that a pull request must meet before merging, on the theory that untested code is where bugs hide.

The number is a genuinely useful smoke alarm: a pricing function sitting at 0% coverage means nobody has ever run it under a test, which is worth flagging immediately. But 100% coverage does not mean the code is correct. A test can execute every line of a function and still assert nothing about the output, or assert something trivially true, or only ever call the function with one easy input while the branch that handles a market-holiday edge case never gets a real check on its logic — coverage only tracks that a line ran, not that its behavior was verified.

This gap matters most in quant code, where the dangerous bugs are usually in rarely-hit branches: a corporate-action adjustment, a leap-year date calculation, a division that only breaks when volume is zero. It is easy to write a test that walks through that branch just to nudge coverage up, without the test ever checking that the branch produces the right number.