I was once obsessed with reaching 100% test coverage. After lighting up every line green, I deployed with confidence, only to face a critical bug. I discuss what coverage doesn't tell you, the dangers of meaningless tests, and the true metric of test quality.
Writing test BEFORE code. Red -> Green -> Refactor. The Double-Entry Bookkeeping of Programming.
'It works on my machine' is no longer an excuse. Robots test (CI) and deploy (CD) when you push code. Deploy 100 times a day with automation pipelines.
Unit tests check the bricks; E2E tests check the building. Learn how to simulate real user journeys using modern tools like Cypress and Playwright. We cover best practices for writing resilient selectors, handling authentication, fighting test flakiness, and where E2E fits in the Testing Pyramid.
Editing a modal inside a dashboard requires 5 clicks to see changes? Isolate your UI with Storybook and develop components 10x faster.
As a junior developer, I was addicted to the 'green bar' shown by Jest Coverage reports.
Seeing Branch Coverage: 85% bothered me.
"If I make this 100%, our code will be bug-free!"
I stayed up nights writing test codes. I forced tests onto simple Getter/Setters and even Catch blocks that seemed impossible to reach. The day I finally hit 100%, I proudly told my team: "You don't have to worry about bugs anymore!"
Then the next day, the payment logic exploded in production.
The cause of the bug was simple. I failed to consider the "Denominator is 0" case in division.
/* Real Code (Coverage 100%) */
function calculateDiscount(price, rate) {
return price / rate;
}
/* Test Code */
test('Calculate Discount', () => {
expect(calculateDiscount(1000, 2)).toBe(500);
});
This code has 100% coverage.
Every line inside calculateDiscount was executed.
But it failed to catch the business logic error where the program crashes or returns Infinity when rate is 0.
Coverage only tells you "Did the code run?", not "Does the code work correctly?". Reading every single word of a book (100% coverage) doesn't mean you understood the content.
Wait to see the worst test I wrote just to pump up the numbers.
/* Meaningless Test */
class User {
constructor(name) {
this.name = name;
}
getName() {
return this.name;
}
}
test('Get User Name', () => {
const user = new User('Ratia');
// Calling getName() increases coverage
expect(user.getName()).toBe('Ratia');
});
This test checks if getName simply returns this.name.
What are the odds of this breaking? Near zero.
But as these tests accumulate, they just increase test execution time and become baggage to maintain whenever refactoring.
Tests solely for filling numbers are technical debt that only increases maintenance costs.
No. Coverage is excellent as an indicator of "What we haven't tested".
Coverage should be a Tool, not a Target. Remember Goodhart's Law:
"When a measure becomes a target, it ceases to be a good measure."
Even big tech companies like Google or Facebook don't aim for 100%. Generally, 60% ~ 80% is considered healthy.
What matters is not "How high is the percentage" but "What did you test". Testing failure cases (exceptions) with lower coverage is far more valuable than hitting 100% by only testing the Happy Path.
Obsessing over numbers leads to hoarding "Cheap Tests". Tests have ranks too.
Recommended Ratio: Unit (50%) : Integration (40%) : E2E (10%)
If coverage feels like homework, flip the order. Don't write code then add tests. Write tests first, then write code to match.
expect(add(1, 2)).toBe(3))This way, "Code without tests cannot exist", so 100% coverage becomes a Natural Consequence, not a goal.
If you are using JavaScript/TypeScript, these are the standard tools.
Confused by testing jargon? Here is a quick guide.
Q. Should I test Private Methods?
A. No. Private methods are Implementation Details. They should be tested implicitly via Public methods. If you export them just to test, you break encapsulation and make refactoring hard.
Q. My test code is longer than production code. Is this right? A. Yes, it's normal. Usually test code is 2-3x longer. Be proud, it means you are defending against various edge cases.
Q. When should I Mock? A. Only for things You cannot control (External APIs, Time, Randomness). For DB or File System, it's easy to spin up Docker containers these days, so use the real thing if possible.
Are you anxious because your coverage is 40%? It's fine. If critical logic is protected, 40% is great.
Are you relaxed because it's 99%? A bug hiding behind those numbers might be laughing at you.
The goal of testing is not to score points, but to "Deploy with Confidence tomorrow". Instead of the green bar, use "Confidence" as your metric.
If you want to dive deeper into testing philosophy: