Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Unit testing code coverage - do you have 100% coverage?

Do your unit tests constitute 100% code coverage? Yes or no, and why or why not.

like image 409
core Avatar asked Sep 25 '09 05:09

core


People also ask

Can code coverage be 100%?

A 100% code coverage does not mean that 100% of lines are covered, but that 100% of the code which must be tested is actually tested.

What would it mean for your code to have 100% coverage?

100% test coverage simply means you've written a sufficient amount of tests to cover every line of code in your application. That's it, nothing more, nothing less. If you've structured your tests correctly, this would theoretically mean you can predict what some input would do to get some output.

What percentage of code coverage do you ensure in unit testing?

With that being said it is generally accepted that 80% coverage is a good goal to aim for. Trying to reach a higher coverage might turn out to be costly, while not necessary producing enough benefit. The first time you run your coverage tool you might find that you have a fairly low percentage of coverage.


2 Answers

No for several reasons :

  • It is really expensive to reach the 100% coverage, compared to the 90% or 95% for a benefit that is not obvious.
  • Even with 100% of coverage, your code is not perfect. Take a look at this method (in fact it depends on which type of coverage you are talking about - branch coverage, line coverage...):


public static String foo(boolean someCondition) {     String bar = null;     if (someCondition) {         bar = "blabla";     }     return bar.trim(); } 

and the unit test:

assertEquals("blabla", foo(true)); 

The test will succeed, and your code coverage is 100%. However, if you add another test:

assertEquals("blabla", foo(false)); 

then you will get a NullPointerException. And as you were at 100% with the first test, you would have not necessarily write the second one!

Generally, I consider that the critical code must be covered at almost 100%, while the other code can be covered at 85-90%

like image 200
Romain Linsolas Avatar answered Oct 20 '22 07:10

Romain Linsolas


To all the 90% coverage tester:

The problem with doing so is that the 10% hard to test code is also the not-trivial code that contains 90% of the bug! This is the conclusion I got empirically after many years of TDD.

And after all this is pretty straightforward conclusion. This 10% hard to test code, is hard to test because it reflect tricky business problem or tricky design flaw or both. These exact reasons that often leads to buggy code.

But also:

  • 100% covered code that decreases with time to less than 100% covered often pinpoints a bug or at least a flaw.
  • 100% covered code used in conjunction with contracts, is the ultimate weapon to lead to live close to bug-free code. Code Contracts and Automated Testing are pretty much the same thing
  • When a bug is discovered in 100% covered code, it is easier to fix. Since the code responsible for the bug is already covered by tests, it shouldn't be hard to write new tests to cover the bug fix.
like image 32
Patrick from NDepend team Avatar answered Oct 20 '22 08:10

Patrick from NDepend team