Short answer is yes.

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.

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.