The 100% Coverage Dogma

The 100% Coverage Dogma

There are teams obsessed with coverage metrics. Every line must be tested, every branch covered. The magic number is 100%.

But coverage isn’t the same as confidence. You can have 100% coverage and tests that don’t validate anything useful. You can have 40% coverage and tests that catch the bugs that matter.

What’s Worth Testing

Core business logic. The code that calculates prices, applies discounts, validates business rules. Errors here have serious consequences.

External integrations. The layer that talks to third-party APIs, databases, external services. Where things can fail for reasons outside your control.

Documented edge cases. Those rare cases that someone discovered, fixed, and that will happen again if there’s no test protecting them.

What’s Probably Not Worth It

Trivial getters and setters. If the code can’t fail, it doesn’t need a test.

UI code that changes constantly. A test that validates that the button has the text “Submit” breaks every time someone changes the copy. High cost, low value.

Code that’s a direct wrapper of libraries. If you’re only calling a lodash function, you’re testing lodash, not your code.

Tests as Documentation

The best tests explain what the code does and why. A good test name is executable documentation.

test('applies 10% discount when cart exceeds 100 euros') tells a story. test('discount function') tells nothing.

The Real Value of TDD

Test-driven development isn’t writing tests first out of dogma. It’s using tests to think about design.

Writing the test first forces you to think about how the code will be used. If the test is hard to write, the code will be hard to use.

Slow Tests Kill the Practice

A test suite that takes minutes to run doesn’t get executed frequently. Tests that don’t run don’t provide value.

Prioritize fast tests that run in seconds. Slow integration tests go in a separate pipeline.

Test Maintenance

Tests are code. Code that needs to be maintained. Fragile tests that break with every internal change generate work without providing protection.

Test behavior, not implementation. If changing how the code is organized breaks tests without changing what it does, the tests are poorly designed.

The Practical Balance

There’s no magic number of tests or correct coverage percentage. There are questions to ask yourself.

Do I have the confidence to make changes without fear? Do the tests catch errors before production? Does the time I invest in tests get recovered in time not spent debugging?

If the answer is yes, you have enough tests. If it’s no, you need more tests in the right places, not more tests everywhere.