Code coverage: How deep should unit test coverage be?

test coverage

It is well known that a program with high code coverage has been more thoroughly tested and has a lower chance of containing software bugs than a program with low code coverage.

Even so, there’s a lot of talk these days about how thorough the unit test coverage should really be. Purists argue that you should strive to achieve 100% test coverage for all your projects while others believe that you should just rely on the quality of the tests and that measuring test coverage does not really tell you much about the quality of the testing effort and the code being tested.

How much testing is enough?

Code coverage: How deep should unit test coverage be?

How much to test is a decision that needs to be made on an individual project basis, taking into account the nature of the project and the stakeholders’ needs. At the end of the day, it depends on multiple factors like: the goals of the project you are working on, the priorities of the people you work with or for and what the software or hardware will be used for in the end and by how many people.

Most of the testers agree that a code coverage of 70-80% is a reasonable goal for the system test of most projects while 100% code coverage would be ideal.

Of course, additional test coverage always means an extra amount of time and effort to be invested for writing those unit test cases and ensuring that the unit test suite executes each and every line of code in the codebase.

Is 100% code coverage necessary for a well-tested program?

A 90-100% code coverage is suitable for a public API, like the java.util Collections, that’s not coupled to a Database and doesn’t return HTML. You can also set a 90-100% coverage goal if you have a business infrastructure code that takes and returns data structures. 100% code coverage also makes perfect sense for critical systems in finance, medicine or life-saving environments.

Although 100% code coverage may appear like a best possible solution, even full code coverage is estimated to only expose about half the faults in a system.

The tester should stop increasing code coverage when the tests become contrived. When you focus more and more on raising the coverage level only for the sake of reaching full coverage, your motivation shifts away from finding bugs.

When do you stop increasing code coverage?

Is 100% test coverage a realistic goal for you?

Leave a Reply

Your email address will not be published. Required fields are marked *