What's a good level of code coverage?

100% code coverage isn't required

As a developer, you might see some libraries in the JavaScript ecosystem with 100% code coverage. You might then wonder, if libraries aim for 100% code coverage, why don't I?

Let me start by saying: Don't let coverage stop you from writing tests. You might be thinking "Oh, but I'll never reach 100% code coverage, what's the point?", but realistically, any tests are better than no tests.

For the apps we build day to day, 100% code coverage is often unrealistic, and suffers from diminishing returns (as in, you'll get less benefit per test written once you pass a certain percentage of code covered). As well as this, it's possible to reach "100% code coverage" without knowing your React components can render properly in all cases (particularly when using Enzyme and shallow()).

What to actually aim for

Don't use code coverage as an arbitrary milestone. Instead, write high quality tests for your most valuable features and components.

Think about it this way, if you were a user for the web app you build, what functionality do you use every day, and would get upset if it stopped working? That's the functionality you need to have covered by tests.

If you then hit 100% code coverage as a result of testing all of your app's functionality - great! But don't let the number be your focus.

Let's talk about test-driven development (TDD) in Chapter 7: Should you use test-driven development (TDD)?

Want to become a better React developer?

I send a single email every two weeks with an article like this one, to help you be a better React developer.

Lots of developers like them, and I'd love to hear what you think as well. You can always unsubscribe.

I'll even send you a free PDF copy of the book you're reading, The Beginner's Guide to React Testing, to start with.

Join 947 React developers that have signed up so far. See my privacy policy.