What is test coverage?

Question

Accepted Answer

**Test coverage** measures how much of the code is **executed by tests** — typically as a percentage (e.g. 80% coverage). It's a useful metric for finding untested code, but it's important to understand its limitations: high coverage doesn't guarantee good tests.

## What coverage measures

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## Why coverage is useful

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## The limitations (important!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## Why it matters

Understanding test coverage — including its limitations — is valuable because it's a **commonly-used metric** that's useful when understood correctly but misleading when misused, so it's important practical knowledge.

Coverage measures **how much code is executed by tests** (as a percentage, via line, branch, function, or statement coverage), and understanding it is useful because it **finds untested code** (revealing gaps where tests are lacking — a valuable way to identify what needs testing), provides a measurable quality signal teams can track, and highlights missed branches and error cases.

Many teams use coverage as a quality metric with targets.

However, understanding the **limitations is critically important**: **high coverage does not equal good tests** — coverage shows code was *executed*, not that its behavior was correctly *verified*, so you can have high (even 100%) coverage with meaningless tests (executing code without proper assertions verifies nothing), and full coverage can still miss bugs (untested input combinations, logic errors).

The danger of **chasing a coverage number** (writing low-value tests just to hit a target) is a real anti-pattern.

Understanding that **coverage is a useful guide for finding gaps, not a guarantee of quality** — and that the focus should be on testing important behavior well rather than hitting a percentage — reflects mature judgment that avoids the common mistake of treating coverage as the goal rather than a tool.

Since coverage is a widely-used metric that's genuinely useful (finding untested code) but commonly misunderstood and misused (treated as a quality guarantee or a target to game), and since understanding both its value and its important limitations enables using it wisely, understanding test coverage is valuable, practically-relevant knowledge — a useful metric to understand correctly, where appreciating its limitations (coverage ≠ quality) is as important as the metric itself, reflecting sound testing judgment.