We’ve been over the concept of testing, and how it is needed to ensure a quality end product. It gives the code we write an earnest attempt to ensure that everything works as expected, and ideally, if there are any gaps where things break found in the process, we close them. The value in a practice that can accomplish all this is priceless! However, all great things come at a cost and can be overextended to the point where it is harmful.

In testing, there definitely is a line between helpful and harmful. That is where our conversation transitions to test coverage, and how to define a proper state of it for your project.

Proper Test Coverage

Before getting into when enough is enough, we first need to look at how to define a proper test coverage. To begin, test coverage itself is the percentage of code covered by a unit test. This is broken out into a few different subsections: functions, lines, statements, and branches. From this subsection, we get a pretty good breakdown of how well your tests cover the files in your project.

With that in mind, going back to the concept of proper test coverage, we take into account all of them to create that concept. Being realistic is important as well. Having 100% coverage across the board is not a goal or something you should strive for. These numbers should be viewed as a means to an end, and not defining values.

Proper test coverage comes from, in my perspective, ensuring all functions are covered and both paths(happy and unhappy) are represented thoroughly. That alone should get you to a minimum percentage level range of around 70% to 85%.

When Is It Enough

We’ve already gone over proper test coverage, and how to define it through testing’s standard subsections. So in theory, we already have an idea of what enough is. Let’s take a more direct approach in defining it though.

  • All functions have associated tests
  • Functions are tested throughly on their happy and unhappy paths
  • Line coverage is an aid, not a defining metric
  • An overall coverage percentage range of 70% to 85%

Simple, straight to it. As you can see, once you define proper test coverage figuring out when enough is enough naturally comes to you. Until you define that, with the needed understanding of each subsection, you won’t be able to grasp the idea enough because you don’t know when it’s complete.

In Closing

In short, understanding what proper test coverage allows you to define what complete test coverage is. From there, you can easily spot out what enough is. Always remember though, 100% coverage is never a goal, only a hindrance. Focus on impact and completeness, not an arbitary percentage number that may not even be fully applicable to your project.