The Problem:

While statement coverage ensures every line executes and branch coverage ensures every decision (e.g., if-else) takes both its true and false paths, these criteria often fall short when dealing with compound boolean expressions. A compound boolean expression combines multiple individual (atomic) conditions using logical operators like AND (&&), OR (||), and NOT (!).

Example Scenario:

Consider a decision if (A && B) { ... }. To achieve 100% branch coverage, you only need two test cases: one where A && B is true (e.g., A=true, B=true) and one where A && B is false (e.g., A=false, B=true).

Notice that in the second case (A=false, B=true), the condition B was never evaluated to false. If there's a bug that only manifests when B is false (e.g., if (A && B) should have been if (A && !B)), branch coverage alone would miss it. The problem is that the individual conditions within the compound expression (A and B) were not thoroughly tested in isolation.

The Need for Deeper Analysis:

This highlights a critical gap. For high-quality software, especially in scenarios where complex logic dictates critical outcomes (e.g., access control, financial calculations, safety systems), simply covering branches isn't enough. We need techniques that ensure every component of a compound decision is thoroughly exercised.

Definition:

Condition Testing is a white-box test case design technique specifically aimed at thoroughly verifying the behavior of logical conditions (boolean expressions) within a program's source code. It goes beyond merely exercising the true/false outcomes of an entire decision and instead focuses on ensuring that each individual, atomic component of a compound condition is evaluated to both true and false, and that these individual evaluations contribute meaningfully to the overall decision.

Primary Goal:

The paramount goal of Condition Testing is to detect errors related to the incorrect formulation or evaluation of boolean expressions. This includes:
- Errors in logical operators (e.g., using && instead of ||).
- Typographical errors in conditions (e.g., x > 5 instead of x >= 5).
- Incorrect variable usage within conditions.
- Missing or superfluous conditions.

Underlying Principle:

It operates on the principle that to thoroughly test a compound condition, each atomic condition (also called a "simple condition" or "predicate") that makes up the compound expression must independently be made to evaluate to both true and false during testing.

3.1. Basic Condition Coverage (BCC): Exercising Each Atomic Condition:

Concept:

This criterion requires that for every simple condition (each individual boolean operand) within a compound decision, both its true and false outcomes must be exercised at least once. It does not necessarily consider the overall decision outcome.

How it Works:

For a condition like (A || B) && C:
- A must be true and A must be false.
- B must be true and B must be false.
- C must be true and C must be false.

Example:

If (X > 10 && Y < 5)
To satisfy Basic Condition Coverage, we need test cases that ensure:
- X > 10 is true (e.g., X=12) AND X > 10 is false (e.g., X=8).
- Y < 5 is true (e.g., Y=3) AND Y < 5 is false (e.g., Y=7).

Sample test cases for BCC:

• TC1: X=12, Y=3 (true && true) -> X>10 true, Y<5 true
• TC2: X=8, Y=7 (false && false) -> X>10 false, Y<5 false
  (This set would achieve BCC for this simple case.)

Limitation:

While it ensures individual conditions are exercised, it doesn't guarantee that the overall decision (the if statement's outcome) will take both its true and false paths in response to independent changes in single conditions.

3.2. Branch/Condition Coverage (BCC + Decision Coverage): A Stronger Combination:

Concept:

This criterion combines the requirements of both Branch Coverage (also known as Decision Coverage) and Basic Condition Coverage. It mandates that:
- Every branch of every decision (true/false paths of if, while, etc.) must be executed.
- Every simple condition within a decision must take on all possible outcomes (true/false).

How it Works:

For each decision statement, you need to ensure that the compound boolean expression evaluates to both true and false. Additionally, for each atomic condition within that expression, you must ensure it individually evaluates to true and false across the test suite.

Advantages:

This is a more comprehensive criterion than either Branch Coverage or Basic Condition Coverage alone. It helps to find bugs related to both the overall decision structure and the internal logic of the component conditions.

Limitation:

It still doesn't guarantee that each simple condition independently influences the outcome of the decision. This means some subtle bugs related to the interaction of conditions could still be missed. This is where MC/DC comes in.

3.3. Modified Condition/Decision Coverage (MC/DC): The Gold Standard (Brief Introduction Here):

Concept:

While we will dedicate the next two lectures to MC/DC, it's important to introduce it here as the pinnacle of condition testing. MC/DC goes beyond Branch/Condition Coverage by requiring that for each simple condition within a decision, you must demonstrate that changing only that condition's value, while holding all other conditions fixed, causes the overall decision's outcome to change.

Goal:

This highly rigorous criterion ensures that every condition genuinely contributes to the decision, and that no single condition is superfluous or incorrectly implemented. It's often mandated for safety-critical software.

4. Practical Derivation of Test Cases for Condition Testing (BCC Example):

Explanation:

Let's take a function canProcessOrder(isCustomerLoggedIn, hasEnoughStock, isValidPayment) which returns true if all conditions are met: (isCustomerLoggedIn && hasEnoughStock && isValidPayment).

Conditions:

A = isCustomerLoggedIn, B = hasEnoughStock, C = isValidPayment.

Target:

Basic Condition Coverage (each A, B, C must be true and false).

Truth Table (partial, focusing on BCC fulfillment):

TC1 makes A, B, C true, covering the true side of each condition and the true outcome of the decision.

TC2 makes A, B, C false, covering the false side of each condition and the false outcome of the decision.

Result:

With just two test cases, we achieve 100% Basic Condition Coverage and 100% Decision Coverage. However, this is for a very simple AND condition. More complex conditions (with ORs, NOTs) would require more test cases to ensure all simple conditions are exercised true/false.

5. Advantages and Limitations of Condition Testing:

5.1. Advantages:

• Improved Defect Detection for Logical Errors: Highly effective at uncovering errors in boolean logic, such as incorrect operators (&& vs. ||), swapped conditions, or missing negations (! operator).
• More Rigorous than Branch Coverage: Goes deeper than just overall decision outcomes, ensuring that the components that build those decisions are properly exercised.
• Enhanced Code Understanding: Forces developers and testers to meticulously analyze compound conditions, leading to a clearer understanding of the expected logical flow.
• Systematic Approach: Provides a structured method for deriving test cases, ensuring that critical logical paths are not overlooked.

5.2. Limitations:

• Doesn't Guarantee Independent Influence: The primary limitation is that even achieving 100% Branch/Condition Coverage does not guarantee that each individual condition independently affects the decision's outcome. This specific guarantee is provided by MC/DC, which requires more sophisticated test case design.
• Combinatorial Explosion for Complex Conditions: For compound conditions with a large number of simple conditions, generating test cases for all possible combinations can become prohibitively expensive, leading to a "combinatorial explosion" problem. This is where MC/DC aims to achieve high confidence with a minimum number of tests.
• Doesn't Address Missing Conditions: Condition testing verifies the conditions that are present in the code. It cannot detect if a crucial condition is entirely missing from the boolean expression, as that would be a requirements defect, not a coding error in the existing logic.