Achieving 100% code coverage will make you a better developer. Seriously.

You’re happy to learn new languages frameworks, so why are not happy to learn testing techniques that will help you for the rest of your career?

Yesterday I wrote about one reason why 100% code coverage is worth aiming for. You can read that post here:

Today I want to discuss another reason why. And this one is even more important than yesterday’s. Here it is:

Possessing the ability to achieve 100% code coverage is an important milestone on your journey to being an expert developer.

Think of 100% coverage as a skill

Coverage is a skill, just like being able to code in JavaScript, TypeScript or Python, and just like being able to use a framework like React, Vue or Django.

If you think achieving 100% coverage is hard, perhaps it’s because you’ve never done it!

Just in the same way React would be hard if you’d never written a React app, 100% coverage is hard to achieve if you’ve never done it.

Now answer this question for yourself:

How many times in your career have you achieved 100% coverage?

If the answer is zero, then what excuse have you been using?

Here’s two:

• code coverage is a useless metric anyway
• code coverage is too expensive / time-intensive for web applications, and only suited when software failure would be catastrophic

“But code coverage is a useless metric!”

I understand why you’re saying that. You think it’s useless because it’s possible to write terrible tests and still achieve 100% coverage. I agree with this.

It is a useless metric. If that’s what you’re using it for. But ironically enough, this is exactly why it’s a useful skill to practice. For two reasons:

One, because full coverage it easy enough to do on its own, but it’s hard to do well.

Two, because we have relatively few developer testing goals that can help us get better at testing.

(We use the term developer testing to distinguish between testing pratices that are useful for developers versus QA testing practices).

So the milestone is actually in three parts:

• Can you achieve 100% coverage?
• Can you achieve 100% coverage by being honest? Without tests that are designed only to increase coverage, like explicit testing of getters/setters?
• Can you achieve 100% coverage without overtesting? (You want just enough tests that you get full coverage without having overlapping execution and without creating brittle tests.)

“100% code coverage isn’t worth bothering about for non-critical software, like web applications”

Again, I can understand why you’re saying this. Web applications, for the most part, aren’t of critical importance. Unlike, say, medical appliances or rocket ships.

When I hear the above what I think is “we don’t know how to achieve full coverage without drastically reducing productivity.”

Which again, is totally understandable. Testing is hard.

But there are many, many experienced developers who are capable of achieving full coverage at speed. They can do that because they were motivated enough to get good at testing it, and they took the time to learn how to do it well.

I’m sold. How can I learn how to do this?

• Start using TDD. You can learn from books like my React TDD book.
• Ask experienced testers to review your tests. Feel free to send PRs my way, I’ll happily look at them!
• Use side projects to learn, so you’re not putting your paid employment at risk when you’re figuring out how to make things work. Carve out some time in your day to learn.

Once you know how to achieve coverage and achieve it well, code coverage becomes far less important…

Personally I very rarely measure code coverage. My TDD workflow means I’m at 100%. That’s not to sound conceited; at some point in my career, getting to 100% coverage was an important goal. But now I know how to do it, I’m working towards other goals.

As I said above, developer testing suffers from having no clear ways of improving, and we have no objective ways of measuring our testing performance.

There are many milestones on the road to be an expert developer; like being able to refactor mercilessly, using TDD and being able to apply the four rules of simple design.

100% coverage is a great first milestone.