When it comes to code coverage, you often hear about the flaws of statement coverage criteria. We're told that statement does not take into account control structures and branches thereof, and is therefore sub-par compared to other criteria such as branch coverage, condition coverage, and even function coverage.

But what are the actual benefits of statement coverage, and to what degree is it used (perhaps in co-agency with other criteria) in industry? Does statement coverage criteria fill needs that other criteria do not?


1 Answer 1


The only advantage of statement coverage is that it is much easier to calculate than other coverage variants. You just need to know if some line of code was executed and calculating coverage ratio is as simple as counting statements that were executed and total count of statements.

With other coverage variants, you have to take account code before and after a statement. You need to figure out which branch of if was taken. If for loop was actually executed. You would also need to complexly calculate all possible paths the code would take and count those to be able to get relative coverage.

Statement coverage is also much easier to visualize. You can just show statements that are covered in green and those that are not in red. But for other coverage variants, it becomes hard to visualize in which branch statement was hit (or not) and by which test.

And the primary reason why it is so much used in industry now is that, being simplest, it was first one used. And users then don't see reason to move to more complex variants (or don't even realize they exist) which creates low demand for actual complex version being implemented and entering people's minds.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.