Why Test Coverage Isn’t the Answer: Limits, Types, and Practical Guidance

When writing production‑grade code, developers often rely on unit tests to gain confidence that behavior matches expectations. Test coverage is a common metric for measuring how much of the code is exercised during testing, and many teams set arbitrary thresholds such as 75%, 80% or 85% as quality gates.

High Coverage Can Be Misleading

Using a simple discount‑calculation function written in Go, the author shows that a single test case can already achieve 100% statement coverage because both if branches are executed, yet two of the four logical input combinations remain untested. Adding more tests does not increase the coverage percentage, exposing the flaw of treating coverage as a definitive quality indicator.

package main

// CalcDiscount returns a discount factor based on age and activity.
func CalcDiscount(userAge int, isUserActive bool) float64 {
    discountMul := 1.0
    if userAge < 18 {
        discountMul *= 0.9 // 10% discount for minors
    }
    if !isUserActive {
        discountMul *= 0.8 // 20% discount for inactive users
    }
    return discountMul
}

Running the test suite with go test -covermode=count -coverprofile=/dev/null reports 100% coverage after the first test case, even though three other input scenarios are missing.

Different Coverage Metrics

Statement coverage measures whether each executable statement runs; a single test can reach 100%.

Branch coverage checks that both true and false outcomes of each conditional are exercised; the same test only covers 50% of the branches in the example.

Path coverage evaluates whether every possible execution path is taken; the example has four paths, and the first test covers only one (25%).

Even achieving 100% branch coverage does not guarantee that all business scenarios are verified. Path coverage is theoretically the most thorough, but in real projects it is often impractical because code changes quickly invalidate the coverage.

Further Illustrations

A second function MinOf that sorts a slice before returning the minimum appears to have only two branches (empty vs. non‑empty), yet the underlying slices.Sort contains its own hidden branches that can affect coverage.

package main
import "slices"

// MinOf returns the smallest integer in a slice.
func MinOf(xs []int) int {
    if len(xs) == 0 {
        panic("empty slice")
    }
    slices.Sort(xs)
    return xs[0]
}

A third example, ComplexCondition, demonstrates that a seemingly two‑path function actually has multiple input combinations, and expanding the condition into explicit nested if statements reveals the true number of paths.

package main

func ComplexCondition(a, b, c bool) bool {
    if a {
        return true
    }
    if b {
        if c {
            return true
        }
        return false
    }
    return false
}

Conclusions and Recommendations

Coverage is a useful early‑warning signal that highlights code never exercised by tests, but 100% statement or branch coverage still leaves substantial risk. Path coverage is rarely achievable in practice, and over‑reliance on arbitrary thresholds (e.g., 75% or 85%) can lead teams to chase numbers instead of addressing real risk.

Focus coverage efforts on critical, business‑logic code rather than boilerplate or glue code.

Strive for high coverage on testable modules, but treat the metric as a guide, not a verdict.

Complement unit‑test coverage with integration, end‑to‑end, and other realistic validation methods.

Avoid setting rigid coverage gates; instead, use coverage to identify gaps and discuss why certain code remains untested.

In short, coverage should be a diagnostic tool, not the final answer to software quality.