Why I Started Caring About This

I used to think 80% test coverage was "good enough." Then I spent time working near systems where software failures don't just crash an app — faulty rod movement in a nuclear plant, they crash planes, stop pacemakers, or release the wrong dose of medication. That changed my thinking completely.

What 100% Coverage Actually Means

Test coverage measures how much of your code is executed during testing. In safety-critical systems — medical devices, avionics, automotive ECUs, nuclear controls — regulators and engineers demand that every single line, branch, and condition be exercised by a test. No exceptions.

  • Statement coverage — every line of code runs at least once
  • Branch coverage — every if/else path is tested, including the paths you hope never trigger
  • MC/DC (Modified Condition/Decision Coverage) — each condition in a decision independently affects the outcome, required by DO-178C for aviation software

My Honest Pros & Cons

✅ Why It's Worth It

  • Unexecuted code is unknown code — if a line was never run in testing, you have zero evidence it behaves correctly under real conditions
  • Regulators require it — standards like DO-178C (aviation), IEC 62304 (medical), ISO 26262 (automotive), and IEC 61508 (industrial) mandate coverage levels as a certification requirement, not a suggestion
  • Forces design clarity — chasing 100% coverage exposes dead code, unreachable branches, and logic errors that would otherwise hide indefinitely
  • Liability and accountability — in the event of a failure, incomplete test coverage is evidence of negligence

❌ What People Get Wrong About It

  • Coverage ≠ correctness — 100% coverage means every line ran, not that every line ran correctly. You still need well-designed assertions
  • It's expensive — writing meaningful tests for every edge case takes significant time and discipline
  • It creates false confidence — teams sometimes hit the number without testing real-world scenarios or failure modes

Pricing: Is It Worth It?

The "cost" here is engineering time — and it's substantial. Proper MC/DC coverage on a complex module can require 3–5× more test code than production code.

But consider the alternative pricing:

  • Boeing 737 MAX MCAS failures: 346 lives, $20B+ in costs
  • Therac-25 radiation overdoses: traced partly to inadequate software testing
  • Toyota unintended acceleration: software defects found during litigation

My take: The cost of 100% coverage is always lower than the cost of a safety-critical failure in the field.

Final Verdict

If you're writing software that controls physical systems, medical devices, or anything where a bug causes irreversible harm — 100% test coverage isn't a best practice, it's the floor. Regulators enforce it, certification bodies audit it, and the physics of failure demand it.

Who must do this: Any team building to DO-178C, ISO 26262, IEC 62304, or IEC 61508 standards.

Who can skip it: Nobody writing safety-critical code. If you think you can, you're likely misclassifying your software's safety integrity level.