Test coverage measures what we've tested; Code coverage measures which code was executed during testing.
Coverage is a quality metric. However, 100% coverage doesn't mean 100% quality. You could have 100% code coverage but still have bugs. But 0% coverage is definitely risky. Coverage shows testing completeness, not quality. The goal is to balance coverage with quality of tests.
Percentage of requirements or features that have been tested
Ensures all business requirements are validated
(Number of requirements tested / Total requirements) × 100
If product has 50 features and we tested 40 → 80% test coverage
Percentage of source code executed by tests
Ensures most/all code paths are exercised during testing
| Type | Description | Example |
|---|---|---|
| Line Coverage (Statement Coverage) | Percentage of code lines executed | Code has 100 lines. Tests execute 80 lines. Coverage = 80% |
| Branch Coverage (Decision Coverage) | Percentage of if/else/switch branches taken | Code has if-else statement. Must test both if=true and if=false for 100% branch coverage |
| Path Coverage (Cyclomatic Complexity) | Percentage of all possible execution paths | Code has 3 if-statements = 2³ = 8 possible paths. Must test all 8 for 100% path coverage |
| Function Coverage | Percentage of functions that are called at least once | Code has 50 functions. Tests call 45 functions. Coverage = 90% |
(Lines of code executed / Total lines of code) × 100
| Level | Target |
|---|---|
| Critical/Safety-Critical | 100% code coverage - Even 1% untested code is risky (healthcare, aviation, banking) |
| High-Risk Financial/Payment | 95%+ code coverage - Payment systems demand high coverage |
| Standard Web/Mobile Apps | 70-80% code coverage - Reasonable balance of effort vs risk |
| Internal Tools/Low-Risk | 50%+ code coverage - Lower priority |
70% of total code coverage (fast, cheap)
20% additional coverage (moderate cost)
10% additional coverage (expensive)
Discount calculation function
Test with 100 normal cases, achieve 100% coverage, but all pass. Function has logic bug (discount > 100% not handled)
Test with 20 cases including edge cases (0% discount, 100%+ discount, null values). Coverage 80% but catches bugs.
You have 70% code coverage. Your manager wants 80%. You need to add 20 new test cases to get there. How do you prioritize which new tests to write?
📊 100% coverage ≠ 100% quality. High coverage with quality tests > Low coverage with quality tests. Aim for 70-80% with good tests.
Interviewers want to see you understand that coverage is a metric, not a goal. Quality > Quantity.