Why are we obsessed with green?
I'll be honest with you: there was a time when I couldn't sleep if my coverage report dropped below 99.8%. I felt like an impostor if even a single line of code, no matter how irrelevant, wasn't covered by a unit test. To me, that number was a badge of honor, irrefutable proof that my code was 'high quality.' But over the years, and after banging my head against the keyboard quite a few times, I've realized that this obsession is often a glaring mistake that pulls us away from what really matters: delivering value.
My experience with the 100% trap
I remember a project I worked on a few years ago vividly. It was a fairly complex financial management app. We wore our purist badges with pride and decided that nothing would go to production without total coverage. At first, it was all laughs and high-fives. Seeing those Jest or Istanbul reports in glowing green gives you an incredible dopamine hit. You feel safe; you think nothing can go wrong.
However, reality gave us a real slap in the face a couple of months later. We had to change the tax calculation logic. It was a small modification in the actual code—maybe ten lines. But do you know what happened? We had to spend three whole days updating the tests. We had tested every single internal implementation detail, private functions, constants... everything. The tests were so rigid that any change, no matter how tiny, broke them all. That’s when I asked myself: are we testing to ensure behavior, or are we testing just for the pleasure of seeing the number 100?
The hidden cost of numerical perfection
What nobody tells you when you start out is that the last 10% or 15% of coverage is the most expensive to achieve and the one that provides the least value. Testing that a UI component renders static text, or that a 'getter' returns what it's supposed to, is usually a massive waste of time. These are tests that don't catch real bugs; they just tell you that you wrote the code you just wrote. It’s pure redundancy.
Then there's the maintenance issue. A test suite with total coverage is usually fragile. If you focus on covering lines rather than behaviors, you end up with code that is tightly coupled to your tests. I've found myself deleting useful tests because I couldn't be bothered to update them after a refactor, simply because they were poorly focused from the start. That is the opposite of what we want from testing, which should be our safety net for refactoring with confidence.
What I’ve learned: Quality over quantity
Nowadays, my approach has changed radically. I no longer look at the overall percentage as if it were the oracle of truth. I’d rather have 70% coverage that covers the critical flows of the application (the 'happy path' and the most likely error cases) than 100% that includes every last 'else' in a console log.
I've learned to prioritize integration tests. They give me much more peace of mind. Knowing that the frontend talks properly to the backend and that the user can complete a purchase process from start to finish is worth much more than a thousand unit tests for isolated functions. If my business logic is well-protected and the main flows work, I sleep soundly, even if the report says I have 82% coverage.
// An example of what I NO LONGER do: testing the obvious
it('should return the correct name', () => {
const user = new User('Roberto');
expect(user.getName()).toBe('Roberto');
});
// What I DO do: testing logic that can actually fail
it('should correctly calculate the discount based on user loyalty years', () => {
const discount = calculateDiscount(userWithFiveYears);
expect(discount).toBe(0.15);
});Final thoughts
Don't get me wrong, I'm not saying you shouldn't test. Testing is fundamental. But we must be pragmatic. Our time as developers is limited and very expensive. Investing hours to get that 100% coverage on trivial code is often a waste of company resources and a source of personal frustration. At the end of the day, what matters is that the software works, is maintainable, and solves real problems.
If you're just starting out, my advice is: don't obsess over the number. Always ask yourself: 'If I change this code tomorrow, will this test help me not break anything, or will it just be a nuisance?' That is the true metric of success. Peace of mind doesn't come from a perfect coverage report, but from knowing your tests protect what really matters to your users.