What is the acceptable code coverage?
This question has been debated for many years in the software development community. Some believe that 100% code coverage is necessary, while others believe it is impossible to achieve.
There isn’t a universally accepted answer to what is the acceptable code coverage. However, as a general rule, aim for code coverage anywhere from 50% to 80%. Acceptable code coverage can vary depending on the company, project, or programming language involved.
This blog post will explore the evidence for and against different code coverage percentages.
What is the code coverage?
There are many ways to measure how well a software project is doing.
In software engineering, code coverage is a metric that helps developers gauge the effectiveness of their unit testing. It measures the percentage of code that is executed by a given test suite.
A high code coverage means that most of the code is being covered by tests, while a low code coverage indicates that parts of the code are not being tested.
Code coverage can be useful for developers, but it is not a perfect measure. Several factors can affect code coverage, such as the type of tests being run and the way the code is written. It is important to take code coverage results with a grain of salt.
When a developer uses code coverage as a primary way to measure the quality of their code, they can end up with a false sense of security. This is because they think higher code coverage means they have done a good job.
This is not true at all.
You should use the code coverage only as a secondary tool for quality assurance. You can use the code coverage tools to find out how much of your code is covered. These tools help you to understand how much of your code is tested.
Some of the coverage tools are:
- dotCover
- NCover
- OpenCover
- NCrunch
- NDepend
To find out which is best for you, read a separate article about them.
Why is code coverage important?
Code coverage is important since it identifies what code is not covered with tests. For example, let’s say you have a payroll application and want to make some changes to the code. You run your tests and see that the code coverage is 10%.
The first thing you should do is to identify what is not being tested. You can do that by looking at the code and asking yourself why certain application parts are not covered.
Then, you should consider testing those parts of the application. Those tests are known as characterization tests. And ensure you don’t break the existing functionality.
Because if you change the part of the application that is not covered with tests, there is a chance that these areas of the code will be buggy when you release them. This can cause a lot of problems for the customers.
Therefore, you must add more tests to cover the code in the application. It is also important to add new tests to cover any new features you add to the application.
Types of code coverage
There are different types of code coverage, but some of the most popular are:
- Function coverage – The function coverage is the percentage of functions the test suite has executed.
- Statement coverage – The statement coverage is the percentage of executable statements that the test suite has executed.
- Branch coverage – The branch coverage is a metric that measures the percentage of conditional branches (for example, branches in the if-else statement) in the source code that is executed during the test.
- Condition coverage – a technique used to test and check variables in the conditional statement.
Don’t worry about the actual type of code coverage. Instead, pick a tool that performs code coverage analysis and see what code coverage result it gives you.
Code coverage vs. code quality
People often mean that high code coverage automatically means high code quality.
But what is code quality, anyway?
Code quality is a measure of how well your code is written. A high code quality means that your code is well organized, well written, and easy to read. Code quality is important because it makes your codebase easier to maintain and extend. It also makes it easier for other developers to understand and work with your code.
There is a difference between code coverage and code quality. Code coverage is the percentage of lines in a program that has been tested. On the other hand, code quality is how many bugs have been found in that code and how easy it is to work with it.
You can get away with having low code coverage if you have high code quality. However, you can have high code coverage and low code quality.
The purpose of code coverage is to find the code that is not covered by tests. This helps identify areas where more testing is needed. You can also use code coverage to find untested code that is unlikely to be executed.
When you find unused code, you can delete it and never worry about maintaining it in the future again.
What is the acceptable code coverage?
Okay, now that we know you shouldn’t primarily use that code coverage as a metric for code quality, what is the actual acceptable code coverage?
Does code coverage need to be 100%?
A common question is whether code coverage needs to be 100%. The answer is no, and here is why:
- It is important to understand that code coverage is not a measure of HOW WELL your source code is tested. Rather, it is a measure of HOW MUCH of your code is being tested. Therefore, 100% code coverage does not guarantee that your code is bug-free. Rather, it just means that your tests execute all code lines.
- 100% code coverage can be difficult to achieve, especially in a large codebase. It is often not worth the effort to get to 100% coverage, especially if it comes at the expense of test quality.
- Even if you do achieve 100% code coverage, new code that is added to the codebase will not be covered by the tests. Therefore, 100% code coverage does not guarantee that you will properly test all future changes to the code.
Overall, 100% code coverage is not necessary for adequate testing. A more important goal is writing high-quality tests covering the most important functionality in your code.
Focus on code that is most likely to be used or changed. Don’t waste time writing unit tests for low business value code. Instead, write unit tests for the code that you are changing. This way, you can ensure that the code works correctly, even after your changes.
There might be some organizations that require 100% code coverage. However, it’s very easy to work around that requirement by adding low-quality tests.
Is 80% good for coverage?
The other common number that appears a lot in the community is that the acceptable coverage is 80%.
In recent years, there has been a growing trend in the software development community to strive for 100% code coverage in tests. Especially if you practice test-driven development (TDD). However, there is also a lot of debate about whether this is achievable or desirable. One of the most common arguments against 100% coverage is that it is not realistic.
However, the 80% coverage target is more achievable and more beneficial. Depending on your application, anything between 50-80% coverage is a good goal.
How to know how many tests are enough? If you can refactor your code safely without fearing that you will break something, or if the tests don’t slow you down, then you have enough tests.
You should aim to improve your coverage. For example, you can write more tests, refactor your code, or eliminate unused code.
How to improve code coverage
There is no one-size-fits-all answer to this question, as the best way to improve code coverage may vary depending on the codebase and the coverage tool being used.
However, some suggested tips for improving code coverage include:
- Write more unit tests. By writing more unit tests, finding bugs and areas that need improvement will be easier. Furthermore, it will also allow for better documentation of the code. As a result, other developers will be able to understand the code better and make fewer mistakes.
- Add integration tests. Integrating tests are a great way to go when it comes to improving code coverage. By adding in tests covering the interactions between various parts of your code, you can better understand how everything is working together. They can uncover potential issues that might otherwise go unnoticed. In addition, integration tests can also help improve the overall quality of your code by helping to ensure that all of the different pieces work together as intended.
- Rewrite code to be easier to test. Code that is difficult to test often has poor code coverage. It is hard to write tests that exercise all the code paths. Rewriting code to be easier to test can improve code coverage. Making code easier to test can be a lot of work. But the benefits are clear: better code coverage and better code quality. The work required upfront can save time and frustration later on.
- Eliminate dead code. The best code is the code that doesn’t exist. It has no bugs or duplication, and you don’t need to test it. It is important to identify unused code when attempting to improve code coverage. If you delete it, you can focus on other areas that may need attention to improve code coverage.
Conclusion
In conclusion, focus on unit testing your most commonly used code paths to improve your code coverage. You can also use test coverage tools to help you identify untested code.
As a general rule, aim for code coverage anywhere from 50% to 80%, depending on how comprehensive the test suite is.
But remember, as with many other things in software development, there are no hard and fast rules regarding code coverage. If you feel you need to test more thoroughly, you can add more tests. If you feel you don’t need to test as thoroughly, you can remove some of the tests.
It is all about testing to meet the needs of your project and the quality of your code.