# How to count condition coverage

I am wondering, What would be the correct condition coverage test cases for the following condition:

``````if(A && E && (B || C || D))
``````

Considering short circuiting, what cases would I need?

EDIT: Sorry I put only a half of the expression

• if you want it easier then split up the condition... Feb 22, 2013 at 14:21
• rathchet freak: Well this is how is the program written. Are my cases correct? Feb 22, 2013 at 14:25

There are many more cases but since you are taking into account short circuiting, then only need to consider one case where A is False and only one case in which A is True and B is True and you don't need to bother checking C. The only time you need to check all three values is if A is True and B is False.

EDIT** With the new expression (A && E && (B || C || D)) With this new expression and still taking into account short cuircuiting, you will only be concerned with the instances where both A is true and E is true. From there, you only need to test B || C || D in that order until you find a true value. So these instances:

``````T--
FT-
FFT
``````

So D will only be checked if B and C are False. C will only be checked in B is false. If B is true, no need to check any further.

Assuming that each of the values is independent of the other (that the value of B does not depend on the value A), then the minimum number of test cases is (true values are cap, false are lower case):

• a
• Ae
• AEB
• AEbC
• AEbcD
• AEbcd

The difficulty with implementing just the minimum number is that if the code changes (extract method refactoring on the conditional) but the business logic does not, it may miss an incorrect result.

• +1 test for all possible (reasonable) combinations not just coverage Feb 23, 2013 at 0:54
• ratchet freak: that is what condition coverage is about..to test both outcomes of all conditions. Feb 23, 2013 at 11:24

In the general case you'll need to check every combination. The code under the `if` may depend on any number of variables, whose state is reflected in tests `A-E`. What if variable `x` is set whenever condition `C` is true, but the execution path through condition `D` doesn't set it? What if calling `D` has side-effects itself that affect the conditional block?

In practice, this kind of code may encapsulate small commonalities between diverse execution paths, and it's hard to get all paths to set up the state correctly. So mistakes of this sort are likely to happen.