Should I aim for 100% test coverage?

Why

• Blast radiususers
• Change frequencyrarely
• Detectabilitysame-day
• Reversibilitytrivial
• Test costmoderate

No, do not aim for 100% coverage; test by risk and use the coverage report to find risky lines that no test runs. The typical case is a team whose tests cover the main paths, asking whether to test the rest: wiring, logging and rare error branches. Blast radius is users, Change frequency is rarely, and Detectability is same-day, because such a failure throws or breaks a page that a user reports. Reversibility is trivial, since a redeploy fixes it, and Test cost is moderate, since each test mocks a rare failure and breaks on refactors. Rule R13 gives Do not test, on the edge: one step toward risk in any factor gives Test minimally for that line.

What breaks if you don't test

For the typical untested remainder, a failure shows the same day: a misspelled config key stops a job, a user reports a broken page, and a redeploy ends it. The damage comes when the uncovered list hides a refund branch or an access check, which fail silently. A percentage does not show which kind of line is missing; the line-by-line report does.

What you lose if you over-test

The last lines cost the most: mocks that throw on the third call, tests for toString(), tests that call main, all breaking when a refactor moves a line. A gate also counts execution, so a test that asserts nothing raises coverage as much as a real one:

import json

DEFAULTS = {"theme": "light", "page_size": 20}

def load_settings(path):
    try:
        with open(path) as f:
            return json.load(f)
    except FileNotFoundError:
        return DEFAULTS

# Written for the gate: covers the except branch, checks nothing
def test_load_settings_missing_file(tmp_path):
    load_settings(tmp_path / "missing.json")

# Checks what the branch returns
def test_missing_file_gives_defaults(tmp_path):
    assert load_settings(tmp_path / "missing.json") == DEFAULTS

Only the second test fails if the branch returns {}. Martin Fowler writes in Test Coverage that he would be suspicious of anything like 100%.

What to do instead

1. Test the main paths and every kind of line in the conditions table.
2. Read the uncovered lines in the report, not the percentage, and run the five factors on each block.
3. Exclude generated code and startup wiring, with # pragma: no cover in coverage.py or your tool's equivalent.
4. For a gate, set a floor at today's number and stricter thresholds on risky folders: Jest's coverageThreshold accepts per-path keys, so ./src/billing/ can require 100% of branches.

When the answer changes

• The code is a library or engine that many products embed, and its branches guard stored data.
• A standard or a contract names a coverage figure.
• The uncovered lines include money, access checks, or silent fallbacks.