Last month, a team I know threw a Slack party because their coverage report hit 100%. Green checkmarks everywhere. The CTO sent a thumbs-up. Two days later, a one-line config change took down production for three hours. The tests were still green. The blanket was warm. The architecture was still made of glass.
Here's the uncomfortable truth: coverage is a comfort metric, not a quality metric. It tells you which lines of code were executed during a test run. It does not tell you whether those tests actually assert anything meaningful. I've seen tests that literally do this:
expect(true).toBe(true);
That's not a test. That's a prayer with syntax.
The moment coverage becomes a target, it stops being a signal. Developers start writing tests to satisfy the tool, not to catch bugs. They mock everything—the database, the API, the clock, the random number generator—until the test is essentially checking that a mock returns what you told it to return. Congratulations, you've tested your mock.
Meanwhile, the real fragility lives in the gaps: the database migration that locks a table for 40 seconds, the timezone bug that only appears on the last Sunday of October, the third-party API that silently changes its response shape, the race condition that only happens when two users click "buy" at the same millisecond. Your unit tests don't see any of that. They're too busy being 100% coverage.
The blanket metaphor is apt because a blanket feels safe. It hides the mess underneath. It lets you sleep at night. But when a real storm hits—a traffic spike, a bad deploy, a dependency outage—a blanket won't save you. You need a roof. You need integration tests, contract tests, staging environments that actually mirror production, and a culture that rewards finding bugs before customers do.
None of that is as easy to measure as a percentage. That's why we cling to coverage. It's a number we can put on a dashboard. It's a number we can argue about in performance reviews. It's a number that makes us feel like we're doing engineering, even when we're just doing arithmetic.
I'm not saying don't write unit tests. I'm saying stop treating 100% as a finish line. A better metric? Mutation testing—does your test suite catch deliberate bugs injected into the code? Or defect escape rate—how many bugs slip through to production per release? Or simply: can you deploy on a Friday afternoon without sweating?
Coverage is a tool, not a trophy. Put down the blanket. Look at the cracks. That's where the real work is.
Top comments (0)