Types of Coverage

Code Coverage

Measures which lines, branches, and functions of source code are executed by automated tests.

Metrics:

  • Line coverage: Percentage of code lines executed
  • Branch coverage: Percentage of conditional branches (if/else, switch) taken
  • Function coverage: Percentage of functions called
  • Statement coverage: Percentage of statements executed

Requirements Coverage

Measures which business requirements have corresponding test cases.

Requirements Traceability Matrix (RTM):

RequirementTest CasesStatus
REQ-001: User loginTC-001, TC-002, TC-0033/3 covered
REQ-002: Password resetTC-010, TC-0112/2 covered
REQ-003: Two-factor auth—NOT covered

Code Coverage Tools

ToolLanguagesIntegration
Istanbul/nycJavaScript/TypeScriptJest, Mocha, Vitest
JaCoCoJavaMaven, Gradle, Jenkins
coverage.pyPythonpytest, unittest
SimpleCovRubyRSpec, Minitest
SonarQubeMulti-languageCI/CD dashboards

Reading Coverage Reports

A typical coverage report shows:

File                    | % Stmts | % Branch | % Funcs | % Lines |
------------------------|---------|----------|---------|---------|
src/auth/login.js       |   95.2  |   88.0   |  100.0  |   95.0  |
src/auth/register.js    |   78.3  |   62.5   |   85.7  |   77.1  |
src/payment/checkout.js |   45.0  |   30.0   |   50.0  |   44.2  |
src/utils/helpers.js    |  100.0  |  100.0   |  100.0  |  100.0  |

How to interpret:

  • login.js at 95% is well-tested
  • register.js at 78% — branch coverage at 62.5% is a gap
  • checkout.js at 45% is critically undertested for a payment module
  • helpers.js at 100% is fully covered (but small utility files are easy)

Setting Coverage Targets

Meaningful Targets

Code AreaSuggested TargetRationale
Payment/financial90%+High business risk
Authentication/security90%+Security critical
Core business logic80%+Primary functionality
API endpoints80%+Integration points
UI components60-70%Visual testing complements
Utilities/helpers70%+Shared code, high reuse
Configuration/setup50%+Less critical

The Coverage Trap

Do not chase 100% coverage blindly. Problems with obsessing over coverage numbers:

  1. Writing meaningless tests — tests that execute code without asserting outcomes
  2. Testing trivial code — getters, setters, configuration that adds no value
  3. Ignoring quality — high coverage with weak assertions is worse than lower coverage with strong assertions
  4. Neglecting other testing — exploratory, performance, security testing matters too

The right approach: Focus on critical paths, business logic, and risk areas. Use coverage reports to identify untested areas, not as a competition for the highest number.

Coverage in CI/CD

Quality Gates

Configure CI/CD to enforce minimum coverage:

# Example: GitHub Actions with coverage check
- name: Run tests with coverage
  run: npm test -- --coverage
- name: Check coverage threshold
  run: |
    npx nyc check-coverage --lines 80 --branches 70 --functions 80

Track coverage over time. Coverage should never decrease after a PR merge. SonarQube’s “New Code” coverage ensures new code meets standards even if legacy code is below target.

Exercise: Analyze a Coverage Report

Given this coverage report for an e-commerce application, identify the risks and recommend actions:

Module              | Line  | Branch | Function |
--------------------|-------|--------|----------|
cart/add-to-cart    | 92%   | 85%    | 100%     |
cart/checkout       | 38%   | 22%    | 45%      |
cart/coupon         | 75%   | 60%    | 80%      |
user/registration   | 88%   | 80%    | 95%      |
user/authentication | 95%   | 92%    | 100%     |
payment/process     | 42%   | 30%    | 50%      |
payment/refund      | 15%   | 10%    | 20%      |
admin/dashboard     | 65%   | 50%    | 70%      |
Solution

Critical Risks:

  1. payment/process at 42% — payment processing is the highest-risk module. 30% branch coverage means most error handling paths are untested.
  2. payment/refund at 15% — critically undertested. Refund bugs cause direct financial loss and customer complaints.
  3. cart/checkout at 38% — checkout is the revenue path. Bugs here mean lost sales.

Recommendations:

  1. Immediate (P1): Increase payment/process to 85%+ and payment/refund to 80%+. Financial modules must have strong coverage.
  2. This sprint (P2): Increase cart/checkout to 80%+. Focus on branch coverage — the 22% means most conditional logic (error handling, edge cases) is not tested.
  3. Next sprint (P3): Increase cart/coupon branch coverage from 60% to 75%+. Coupon edge cases (expired, minimum order, combination rules) are common bug sources.
  4. Set quality gate: New code in payment and checkout modules must have 85%+ coverage. Block PRs that decrease coverage in these modules.
  5. No action needed: user/authentication and cart/add-to-cart are well-covered. admin/dashboard at 65% is acceptable for admin features.

Key Takeaways

  • Code coverage measures test execution; requirements coverage measures business requirement mapping
  • Branch coverage is more valuable than line coverage — it reveals untested conditional logic
  • Focus coverage targets on risk: payment and security modules need 90%+, utilities can be lower
  • Do not chase 100% — focus on meaningful assertions over executed lines
  • Use CI/CD quality gates to prevent coverage regression
  • Coverage reports identify gaps — they are diagnostic tools, not goals in themselves