Code coverage is a vital part of test automation. It allows us to get a good feel for how well a system is covered and even which parts of the system need some more love.
Through my career, the guidelines have always been to aim for around 80% code coverage. There has always been a warning against the folly of chasing 100%. Part of that guideline was pragmatism. Back in the days of handcrafted unit tests, chasing down those last percentage points was a time-consuming effort with diminishing returns. That time was better spent on feature work.
But there was a second component to the warning. Good test automation tests behaviour, not implementation. To the test, it doesn’t matter how the sum() function arrives at the conclusion, as long as 1+1=2. Chasing down those last percentages of code coverage meant testing implementation details and mocking other parts of the system. We were building brittle systems that said little about the real world and would break when the internals changed, even if the behaviour was exactly the same.
But lately, as coding agents have taken the industry by storm, it’s starting to dawn on me that these old rules might be outdated. I’m getting more convinced that we need 100% code coverage.
The argument around effort and diminishing returns is moot. Claude can write tests all night long. Effort is zero. Sure, these tests might not win a beauty contest, but as long as they increment the coverage metric, they help.
It’s the second argument that is the most interesting one: we want brittle tests! Coding agents can create changes with the precision of a surgeon. They read the entire codebase and find the single line that needs changing. Or, in the other 30% of cases, they act like a drunk raiding the fridge. They’ll start big refactors and make things more complicated than necessary. When enforcing 100% code coverage, the drunks will stand out immediately.
For every PR my agents create, there is an automated check that verifies 100% code coverage is maintained and that new tests are added. But it also flags which existing tests are changed. It’s an amazingly effective guardrail.
You open a PR and rather than look at the code, you look at the impacted tests. Added 2 tests and didn’t touch the rest? Good to go! Changed the Sign-up flow and Claude also changed the sign-up tests? Makes sense. But often, you’ll immediately spot a weird one. Wait? Why did it touch the Invoice tests?
Those moments either uncover a drunk or, more interestingly, a side effect of the change you weren’t aware of.
100% code coverage gives us a clear, cheap sign the agent has done something unexpectedly.
In the age of no longer reading the code, that is gold.