Glossary
Code coverage measures the percentage of code executed by tests—a floor metric ensuring critical paths are at least validated once.
By the Glue Team
Code coverage is the percentage of code executed by automated tests. It measures what tests are checking. 100% coverage means tests exercise every line of code. 0% coverage means no tests. Coverage is useful but not sufficient—bad tests can achieve high coverage.
Code coverage includes:
Risk Reduction: Uncovered code is untested. It's where bugs hide. Coverage shows what's at risk.
Change Confidence: If code is well-covered, you can refactor confidently. Changes fail fast in tests.
Regression Prevention: Tests catch regressions. Untested code regresses silently.
Quality Indicator: High coverage (with good tests) correlates with quality. Low coverage indicates risk.
"100% coverage means no bugs." False. Bad tests can achieve high coverage. 70% coverage with good tests is better than 100% with pointless tests.
"Coverage is the only quality metric." False. Code review, architecture, testing practices matter too.
"We should achieve 100% coverage." False. Target 70-80% on critical paths. Some code doesn't need testing (getters, trivial code).
Testing: Coverage measures testing effectiveness.
Code Health: Coverage is one dimension.
Technical Debt: Untested code is debt.
Q: What's a good coverage target? A: 70%+ on critical code is good. 50-70% is acceptable. 0-50% indicates risk.
Q: Should you add tests to existing code? A: Add tests for changed code. Incrementally improve coverage for high-risk code.
Q: How do you improve coverage? A: Write tests for untested paths. Focus on error cases and edge cases first.
Keep reading
