You don’t need 100% coverage.

Before thinking about going for the sweet 100%… do you, at least, have enough tests?
Getting 100% for any feature you have is awesome, don’t get me wrong. But if you don’t have enough tests for most of your application, then you don’t need that 100%.

Cover all the happy paths first

The least your application should do is work as you intended when you use it as intended.

This means covering all your happy paths first.

Cover the core features

Your core features, also those more critical, are bound to give you more grief.

Being important to you, you probably want 100% for them first.

Out of everything, your most critical places should have 100%. (And probably some more, because of possible problems you can have and edge cases that will give you redundancy.)

Cover the main error paths

What happens when someone tries a wrong password or if your API returns that they aren’t authorized to do something?

There are many expected errors you can have and you should also cover those paths.

Got a bug? Replicate on tests!

For bugs, it doesn’t matter if you’re already covered (and if you got a bug, then you probably aren’t covered).

Got a bug, replicate it in a test and never bother about it again.

New features can start at 100% (or almost it)

Depending on where you are in testing everything if you started to commit yourself to testing your application, it’s a no-brainer that new features can start with already 100%, or as close as possible.

Go for 100%?

Before getting to 100%, and you probably don’t even need that 100%, you probably will need to check if those tests you already have are actually covering what your coverage says it does.

You can “easily” cover 100%, but if you keep having bugs and other problems even on tested grounds, then those 100% might not be worth anything and you should improve if what you’re testing is actually testing what you want.

Beyond 100% (even without 100%)

By now, you would have a high percentage, maybe even in the ninety percent range.

So you have a choice… because climbing the last percent to 100% is costly and might not be worth it, you can think about adding redundancy or doing other types of testing.

You probably would have lots of units and integration testing, so now you could think about e2e tests, maybe load and other types of stress testing, or how about some mutation tests?

Cover Photo by Clay Banks on Unsplash