Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have encountered (even in literature) two contradicting opinions related to path vs condition coverage (not branch or edge!). Some say Path coverage is stronger than the condition coverage, some say the opposite.

Having code like this:

If(X<0 OR X>100)
   DoStuff();

Path coverage - 1 test case is needed to cover the path. With X=-1, the second expression will not be tested and possible bug will be missed.
Condition coverage - test cases X=-1 and X=100 are needed to test both conditions.

Am I missing something or condition coverage is really stronger than path coverage?

Condition coverage (ISTQB):

Our next level of coverage is called condition coverage. The basic concept is that, when a decision is made by a complex expression that eventually evaluates to TRUE or FALSE, we want to make sure that each atomic condition is tested both ways.

Practical Insight Into CMMI

Condition coverage measures the true and false outcome of each Boolean subexpression.

References:

Software Testing: Principles and Practices from Srinivasan Desikan,Gopalaswamy Ramesh: page 61

Condition coverage is a much stronger criteria than path coverage, which in turns is a much stronger criteria than statement coverage.

share|improve this question
    
According to every definition of "path coverage" I can find, three test cases would be necessary to fully cover the if block, one for each of the three possible execution paths. What definition are you using? –  Rogério Apr 11 '13 at 18:18
    
@Rogerio You are confusing the defition with condition coverage. If branches into 2 paths. In that example, you need the condition to be true to test the path) or false (to test the other path). Path coverage does not care about sub-expressions, it is what it is - path coverage. –  user970696 Apr 13 '13 at 16:47
    
@user970696 No. Any correct definition of path coverage cannot take into account the syntax of the programming language. The only thing in a method/routine that affects its number of paths is the occurrence of "branching points", aka "conditional branches". An "if" translates to a branching point, just like a short-circuit "and/or" operator. Wikipedia (at en.wikipedia.org/wiki/Short-circuit_evaluation) even says that "Short-circuit operators are, in effect, control structures". So, in that example, we have two branching points and three paths. –  Rogério Apr 15 '13 at 19:56
    
The example you give is also known as boundary testing –  Chris S Dec 12 '13 at 16:48

5 Answers 5

up vote 3 down vote accepted

Neither one is "stronger" in the mathematical sense:

  • Path coverage does not imply condition coverage, as illustrated by an example in your question
  • Condition coverage does not imply path coverage, as illustrated by your comment (condition IF(A&&B) with pairs A=TRUE, B=FALSE and A=FALSE, B=TRUE).

This means that claims that either side is somehow "stronger" would be invalid.

If you "upgrade" the condition coverage to modified condition/decision coverage, however, the answer would be "yes": MC/DC always implies covering the path, but covering the path may not necessarily imply even covering the condition, let alone MC/DC.

However, this does not imply that 100% MC/DC is always better than path coverage: the tradeoff is that it comes at much steeper "price" than a 100% path coverage due to the need to write more tests. Sometimes, a lot more. This has a potential of complicating the maintenance of your test suite.

I think it is a good idea to maintain a good balance between condition/decision coverage and path coverage by path-covering simple conditions (such as argument checks of the "null or empty" sort) and condition/decision-covering statements with complex business logic.

share|improve this answer
    
I would not say covering a condition always implies covering a path - e.g. IF(A&&B). You need two cases for 100% condition coverage - A=TRUE, B=FALSE and A=FALSE, B=TRUE. But both test cases results in FALSE, yet both subexpression were tested. This is solved by decision/condition coverage, –  user970696 Feb 4 '13 at 20:37
    
@user970696 Oops, I always thought that MC/DC was the condition coverage! I'm updating the answer for this. –  dasblinkenlight Feb 4 '13 at 21:03
    
Thanks. For "simple" condition coverage, do you still think it is stronger than path? Thanks again. –  user970696 Feb 4 '13 at 21:05
    
@user970696 I fixed the answer. I do not think that condition coverage is stronger or weaker than path coverage. –  dasblinkenlight Feb 4 '13 at 21:37
1  
I don't think your first bullet point (or the same remark in the question) is correct; given 1 if statement, there's 2 paths, not 1. You can enter it, or not. For complete path coverage, you must test both. –  Izkata Feb 5 '13 at 3:10

As already mentioned, neither

  1. Path Coverage implies Condition Coverage NOR
  2. Condition Coverage implies Path Coverage

There are very simple examples which proof that:

(1): Path Coverage doesn't imply Condition Coverage:

if (A and B) then
    some elementary statement(s)
end if

Path Coverage is provided by:

  • A = false
  • A = true and B = true

But: For Condition Coverage we require A = true and B = false as well.

(2): Condition Coverage doesn't imply Path Coverage:

if (A)
    some elementary statement(s)
end if
if (B)
    some (other) elementary statement(s)
end

Condition Coverage is provided by:

  • A = false and B = false
  • A = true and B = true

But: For Path Coverage we require A = false and B = true as well as A = true and B = false.

share|improve this answer

Path coverage basically includes the coverage of the statements in the program that you have written.That is if the program contains the following lines of code as: 1. if(condition 1) 2. then call a function; 3. else 4. call that function; 5. call another function; So if we now closely observe the code we will find that there are 5 statements in total and the two of those statements are actually conditions. So a path coverage will start from the first path and will check if the condition is true. If not then it will switch to the else part and execute the statement 4 and 5.Thus in all the number of statements covered are 1,3,4,5. Whereas in the condition coverage the if and the else part are checked only not the 5th statement i.e. only statements 1 and 3 are checked. But also note that if there were only conditions then here in this case path coverage=statement coverage.

share|improve this answer

The main difference between condition coverage and path coverage is that condition coverage is local to some control structure (if, while, for, ...), whereas path coverage is global to the whole program and therefore includes all possible combinations of branches (not conditions).

On the local point of view, condition coverage is stronger.

On the global point of view, path coverage is stronger. So stronger that it is usually not achievable.

share|improve this answer

Path coverage is strictly more complete than branch coverage.

An example pulled from Wikipedia:

two properties of the cyclomatic complexity, M, for a specific module:

  • M is an upper bound for the number of test cases that are necessary to achieve a complete branch coverage.
  • M is a lower bound for the number of paths through the control flow graph (CFG).
if( c1() )
   f1();
else
   f2();

if( c2() )
   f3();
else
   f4();

In this example, two test cases are sufficient to achieve a complete branch coverage, while four are necessary for complete path coverage. The cyclomatic complexity of the program is 3 (as the strongly connected graph for the program contains 9 edges, 7 nodes and 1 connected component) (9-7+1).

Cyclomatic complexity example

However, as noted a little further down (bolding mine for emphasis):

Unfortunately, it is not always practical to test all possible paths through a program. Considering the example above, each time an additional if-then-else statement is added, the number of possible paths doubles. As the program grew in this fashion, it would quickly reach the point where testing all of the paths was impractical.

EDIT

Okay, I think I see where @user970696 in the comments is coming from. If I understand right, the answer is still strictly path coverage. The only time you'll have a "special" result different from branch coverage is when there's functions being called in the conditional, which may or may not run due to short-circuiting.

But when that happens, they count as part of the path.

Take this, for example:

if (a() && b()):
   foo()
else:
   bar()
  • Branch coverage has 2 cases:
    • (a() && b()) == True
    • (a() && b()) == False
  • Conditional coverage has 3 cases:
    • a() == False
    • a() == True && b() == False
    • a() == True && b() == True
  • Path coverage has the same 3 cases:
    • Path: a(), bar()
    • Path: a(), b(), bar()
    • Path: a(), b(), foo()

However, when you add in a second if statement, as mentioned above, the number of paths will multiply - while each individual if statement stays at the same complexity.

share|improve this answer
2  
But we are not speaking about BRANCH but CONDITION coverage, which is not the same. –  user970696 Feb 4 '13 at 19:14
    
@user970696 Please remember that this from Wikipedia, and it is using branch consistently with its page on branch (computer science) which describes a branch as "A branch is sequence of code in a computer program which is conditionally executed depending on how the flow of control is altered at the branching point." If you are using a different definition of branch and condition, you will need to remember to translate that in your head to what you think it is. –  MichaelT Feb 4 '13 at 19:24
1  
MichaelT: We are not speaking about branch coverage at all. We are speaking here about condition coverage which is something else - it measures the false and true outcomes of each boolean subexpression. It is term used everywhere in the literature. I will add some quotes to original question. –  user970696 Feb 4 '13 at 19:28
1  
The principle of condition coverage is - unlike branch coverage - to test ALL subexpression in the condition, not just the overall outcome. –  user970696 Feb 4 '13 at 19:34
1  
@user970696 No, subexpressions are definitely counted, as they may have further branches inside of them. –  Izkata Feb 4 '13 at 21:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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