Coverage-Based Testing

1 The Hook — Why This Matters

In 2021, a Wellington fintech startup shipped a GST calculation module that had passed all 47 unit tests with 100% statement coverage. Yet on launch day, a Christchurch exporter was charged GST on a zero-rated export sale. The bug was in a compound condition: if (isRegistered && amount > 0 && !isExport). The tests had exercised every line, but never the case where isRegistered was false while amount > 0 was true. Statement coverage was green. Branch coverage was green. Condition coverage was red.

The startup had to issue refunds, absorb the processing fees, and rebuild trust with their first enterprise client. 100% statement coverage gave them false confidence. The gap wasn't in their tests — it was in their understanding of what coverage actually measures.

2 The Rule — The One-Sentence Version

Each coverage type asks a different question. Statement coverage asks "did every line run?" Branch coverage asks "did every decision go both ways?" Condition coverage asks "did every boolean sub-expression go both ways?" Path coverage asks "did every unique route through the code execute?" Higher coverage types find bugs that lower types miss — but no coverage metric finds bugs in code that was never written.

3 The Analogy — Think Of It Like...

4 Watch Me Do It — Step by Step

Here is a real NZ example using a GST calculation function. Follow these steps every time you analyse coverage data.

function calculateGST(amount, isRegistered, isExport) {
  if (isRegistered && amount > 0 && !isExport) {
    return amount * 0.15;          // line 3
  }
  if (!isRegistered) {
    throw new Error('Not registered'); // line 6
  }
  return 0;                          // line 8
}

1. Obtain the coverage report Run your test suite with a coverage tool (Istanbul, JaCoCo, Coverage.py). Export branch and condition coverage, not just statement.
2. Sort by branch coverage, not statement Statement coverage is the weakest metric. A function with 100% statement coverage can still have untested branches. Sort your report by branch coverage ascending to find the riskiest gaps first.
3. Map untested branches to risk For the GST function above, the if on line 2 has one decision with three conditions. Branch coverage tests the whole decision true/false. If false is never hit, export sales may be incorrectly taxed.
4. Design targeted tests for uncovered branches
   • Branch true: isRegistered=true, amount=100, isExport=false → GST = 15
   • Branch false: isRegistered=false → throws error
5. Verify condition coverage for compound decisions Condition coverage tests each boolean sub-expression independently. For isRegistered && amount > 0 && !isExport, you need tests where each condition is true and false while the others keep the decision reachable.

   isRegistered	amount > 0	!isExport	Decision	Coverage
   true	true	true	true	All true
   false	true	true	false	isRegistered false
   true	false	true	false	amount false
   true	true	false	false	isExport false

6. Measure path coverage for critical flows Path coverage tests every unique combination. For this function there are fewer than eight paths because the second if depends on the first. Trace the control flow graph and identify which paths are infeasible (dead code) versus merely untested.
7. Re-run and compare before/after Document the coverage delta in your pull request. Coverage should increase meaningfully, not by writing do-nothing tests.

5 When to Use It / When NOT to Use It

6 Common Mistakes — Don't Do This

7 Now You Try — Interview Warm-Up

if (age >= 18 && hasConsent) {
  process();
} else {
  reject();
}

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to apply this on the job.

9 Interview Prep — Common Questions