I don’t buy the hype around chasing perfect code coverage anymore. Coverage metrics can help, and I still use them, but I’ve watched enough teams cheer at hitting 100% only to discover that real bugs still sneak through. We’d get the green bar, everyone would feel relieved, and then the next release would blow up because a test missed something obvious. I’ve reviewed codebases where a test simply called a function and finished with expect(true).toBe(true). No real check, just enough to keep the coverage gate happy.
The problem isn’t just bad tests. Coverage itself can feel like a safety net, even when a single untested edge case could still crash the app. Chasing a number turns into a distraction. For “statement” coverage, all you know is that a line ran at least once. You don’t know if it did the right thing or if it breaks the moment a real user does something unexpected.
If you want software that holds up in production, the green bar alone isn’t enough. It never has been.
Code coverage tells you how much of your program runs when you launch your tests. Most teams track three basic numbers:
Sometimes you’ll hear about path coverage in textbooks. That’s every possible route through a block of code. Each new branch doubles the number of paths, so it quickly grows out of control, even in small files. No mainstream tool tracks every path in real-world projects, so nobody tries.
Here’s what coverage actually means in practice: suppose you have a function that adds two numbers. If you call it once, say, with add(2, 3)and never check the result, your test can hit 100% coverage. Even if the function is broken and always returns 0, the number turns green. Coverage only shows that code was executed, not that it worked as intended. Good tests don't just run code. They actively assert correctness, handle weird edge cases, and try unexpected inputs.
You can call a function, skip any assertion, and still see your coverage climb. Higher coverage just means more of your code is executed during a test run. It doesn’t say the results were right.
Coverage numbers always look scientific, right up until real life gets in the way. I’ve been on teams that bragged about hitting 100% and then watched the app break the moment a user did something weird. Those green bars miss a lot.
Take statement coverage. It just wants to know if a line ran once. It doesn’t care about the result or whether you only tried the easy cases. I’ve lost count of tests that “covered” the code but never checked what happens if you pass zero, a negative number, or even a string. For instance, testing divide(4, 2) but never divide(4, 0). The bar lights up, but nothing meaningful gets tested.
Branch coverage? It’s not much better. Sure, you might flip an “if” from true to false, but that doesn’t mean you tried all the odd combinations. The hardest bugs show up in those tangled cases. When it’s not just “yes” or “no,” but “what if this, and that, and the config is half-missing?”
Path coverage is theoretical for most teams. The number of possible routes explodes so fast that nobody tracks them all. Everyone ends up focusing on what’s easy to measure and letting the rest slide.
The tooling isn’t foolproof either. Istanbul, nyc — take your pick. I’ve seen them show “100%” when an instrumentation step is misconfigured or when broken source maps hide whole files from the report. TypeScript and modern bundlers make it even fuzzier. Sometimes the dashboard glows green while important code isn’t counted at all.
Your testing style matters too. Snapshot tests in Jest? I’ve seen them bump up coverage overnight. But half the time, they just confirm the UI stayed the same, while a real bug in the logic goes unnoticed. You might catch a typo, but you’ll miss the defect that actually matters.
The worst trap is never sending the wrong inputs. If your tests only check positive numbers, nobody sees the function crash on zero, null, or the weird value an actual user finds. Coverage still flashes “100%.” That broken path never runs, and the bug stays hidden.
So yes, high coverage feels comforting, but it rarely means you’re safe. The real risk is the gap it hides, the one that always finds you in production.
Coverage is easy to measure and even easier to chase. I’ve seen plenty of teams, including my own, set 100% as the target. We told ourselves that meant our software was safe. It never worked out that way.
You see it in the little things. Someone writes a test not to catch a bug, but simply to turn the bar green. This encourages a culture where hitting metrics matters more than quality. And that’s dangerous. I’ve reviewed last-minute “tests” that just call a function, skip real checks, or copy and paste from somewhere else. Anything to get past the coverage gate.
A friend of mine once told me that he worked with a team that hit perfect coverage before production deployment. The dashboard was solid green. Two days later, a user got someone else’s invoice by email. A brutal privacy bug. The code that failed was covered by tests, but the tests only checked if the API didn’t throw an error. They never checked if the right invoice went to the right person. The number was perfect, but the safety wasn’t real.
It gets worse when 100% coverage becomes a hard rule. If the build fails unless you hit the number, everyone learns how to game the system. Tight deadlines only make the shallow tests multiply. That coverage score becomes a badge of pride, but it’s just a number. Sooner or later, a bug gets through, and you realize those tests would never have caught it.
This is the real trap. Coverage metrics are easy to fake. They give you the feeling of control, but that control is an illusion. I learned the hard way: when you focus on the number, you miss the point. Coverage only proves the code ran. It says nothing about trust.
I’ll never forget the first time I shipped a bug in code that supposedly had 100% coverage. The bar was green. We even bragged about it in stand-up. Then a user sent our function a negative number, and everything crashed.
That’s the thing about coverage. You can run every line, hit every branch, and still miss the scenarios nobody thought of. Here’s what I’ve seen go wrong, sometimes in my own commits, sometimes on teams I’ve worked with:
We wrote tests for positive numbers. We covered calculateDiscount(50) easily. But zero? Negatives? calculateDiscount(0) or calculateDiscount(-10) weren't even considered until users hit them in production.
I’ve reviewed pull requests where the only check was that a function didn’t throw. The test passed, but the actual result was wrong, and our coverage report cheered us on.
The worst is a test that runs every function and then just asserts true === true. I’ve done this at 1 a.m. just to get CI to pass, promising myself I’d write a real test later. (Spoiler: I never did.)
These mistakes sneak in all the time, especially when you start caring more about the number than the test itself. Coverage just tells you what code ran. It won’t save you from logic bugs, missed scenarios, or shallow checks that hide real risk behind a green bar.
I’ll be honest, my view on test safety changed the first time I saw a “100% covered” build blow up on a real user’s interaction. Since then, I’ve watched the best teams break away from chasing numbers and focus on what actually keeps bugs out. Here’s what they do in practice:
The best property-based tests don’t just check expected inputs. I’ve seen teams use property-based testing tools like fast-check in JavaScript to automatically generate hundreds or even thousands of diverse inputs, including zeroes, negatives, nulls, and huge numbers. Once, simply adding zero revealed a divide-by-zero bug lurking beneath supposedly "complete" coverage.
Mutation testing feels ruthless. Stryker flips a plus to a minus or makes a branch unreachable. The first time I ran it, half my tests missed the change, which stung but made the code stronger.
You can’t test every helper or every boring utility. So the teams I trust spend their energy on the parts that actually keep them up at night: payment logic, permissions, anything that could break trust with a user or cost real money. I’ve seen teams write quick checks for things like formatting helpers, but for anything tied to money, the database, or real user data, they get relentless. They try every weird input, even the ones that seem impossible. That’s where the real work goes.
Code review isn’t just for nitpicking style. The best reviewers always ask, “What if this fails? What did we forget?” I’ve seen more bugs caught in Slack threads or PR comments than any dashboard metric.
Nobody gets it right the first time. Logs, error alerts, even a spike in user complaints. Every signal is a chance to learn. The strongest teams feed those lessons straight back into their next round of tests.
There’s no silver bullet, just messy, honest work. The teams I trust don’t just run tools. They keep asking, “What did we miss?” Every outage or near miss is another reason to dig deeper the next time.
Code coverage is just a map. A useful but incomplete map. It’s handy for identifying parts of your code you never tested, but it can’t guarantee the logic underneath is correct. The best teams I’ve seen combine coverage metrics with careful tests, intentional edge-case exploration, and thoughtful code reviews.
I’ve watched teams chase 100% coverage, only to ship bugs hiding in plain sight. Numbers are comforting. They can also be a trap.
You can run every line in your tests and still miss the scenarios that actually hurt your users. Real safety doesn’t come from a green bar. It comes from the tough questions we ask in code review, the logs we read after launch, and the times we go back and patch what we missed. Real software safety comes from that deeper work, not just chasing 100% coverage.
The best teams I’ve worked with treat coverage as a tool, not a trophy. We argue about tests, delete the pointless ones, and spend more time than we’d like asking what could actually go wrong. I’ve seen plenty of us chase the green bar, then get blindsided by a nasty edge case in production. Those moments stick with you.
Reliable software never comes from chasing a number. It comes from asking the awkward questions, listening when things break, and owning what you still don’t know. Real confidence grows in the mess, not in the percentage.
Viz
Become a subscriber receive the latest updates in your inbox.
Member discussion