What is Path Testing with Examples

Shilpa Prabhudesai

Software testing is generally perceived as verifying whether a program functions as expected when a limited set of inputs is provided. But this is not so. In addition to testing a program for a few inputs, it is also necessary to ensure that all logical paths inside the program behave correctly. This is where Path Testing makes its presence felt.

This article explores the concept of path testing, its importance, working process, and its advantages and challenges. The article also demonstrates the path testing process using various examples to help you understand the concept clearly.

What Is Path Testing?

Path Testing is a white-box testing technique that includes designing test cases to execute all possible execution paths in a program.

Read Black-Box and White-Box Testing: Key Differences for more information on white-box testing.

A path is defined as a unique sequence of statements and decision outcomes from the program’s entry point to its exit.

The primary goal of path testing is to ensure that every statement and condition in a source code has been executed at least once. Path testing focuses on the control flow of the program, examining the sequence of instructions from start to finish.

• What path should be followed if a condition is true?
• What happens if the same condition is false?
• What if the source code has multiple conditions interacting in different combinations?

• Detect logical flaws in branching or looping constructs.
• Identify incorrect conditional statements.
• Find missing or unreachable code and identify unused branches.
• Uncover loop-related defects.
• Ensure complete code coverage for improved software quality.

The path testing method is based on the internal structure of the code, so testers must understand the program logic to apply it effectively.

Benefits of Path Testing

• Ensures Logical Correctness: Path testing ensures logical correctness of the application by providing confidence that the application’s underlying logic aligns with the intended design and functionality.
• Identifies Hidden Defects: There are always some hard-to-detect defects in applications that appear only when a specific sequence of conditions is executed. Path testing systematically evaluates the program’s flow, helping testers uncover hidden defects.
• Improves Code Coverage: The primary objective of path testing is to ensure that every logical path and branch in the source code is executed and verified at least once. This statement, branch, and decision coverage helps find bugs in every part of the application, including less frequently executed source code areas.
• Facilitates Early Defect Detection: Developers perform path testing at the unit level. Hence, defects, if any, caught early in the Software Development Life Cycle (SDLC) significantly reduce the time and cost required to fix them later.
• Reduces Redundant Tests: In path testing, a “basis set” of independent paths is identified that minimizes redundant test cases, making the testing process more efficient and maximizing coverage.
• Detects Dead or Unreachable Code: Paths that can never be executed indicate unnecessary or flawed code, which path testing helps identify.
• Improves Software Quality and Reliability: The path testing method ensures that software functions as expected under various conditions, leading to a more reliable and robust application.
• Aids in Analytical Test Case Design: With metrics such as cyclomatic complexity, path testing enables the determination of the minimum number of test cases required for complete branch coverage, providing a structured and systematic approach to test design rather than arbitrary test creation.
• Supports Maintenance and Integration Testing: Path testing ensures that changes do not negatively impact existing functionalities and prevent interface errors between modules.

Key Concepts Used in Path Testing

1. Control Flow Graph (CFG)

A CFG is a directed graph that represents a program’s or module’s control structure. A control flow graph CFG (V, E), is a graph of V number of nodes/vertices and E number of edges.

In CFG, nodes or vertices (V) represent statements or blocks of code, and edges (E) represent the flow of control between nodes.

A control graph can also include the following:

• Junction Node: A node with multiple arrows entering it.
• Decision Node: A node having more than one arrow leaving it.
• Region: The area enclosed by edges and nodes is referred to as a region (the area outside the graph is also considered a region).

Path testing is typically performed using a CFG.

2. Independent Path

An independent path in a CFG is a path or a route that introduces at least one new edge that has not been traversed in any previously defined path.

When all the independent paths are tested, you can ensure there is no redundancy and that maximum logical coverage is achieved.

The cyclomatic complexity of a CFG represents the number of independent pathways present. It serves as an upper limit for the number of tests that should be run to ensure that all of the program’s statements have been executed at least once.

3. Cyclomatic Complexity

Cyclomatic Complexity (CC), typically represented as V(G), is a metric that indicates the program’s logical complexity. It denotes the number of independent paths in a program.

V(G) = E - N + 2*P

Here, E => Number of edges,

N=> Number of vertices,

P=> Number of connected components.

CC = Number of decision points + 1

Cyclomatic complexity helps determine the number of path test cases required.

Path Testing Process Steps

The path testing process typically is a sequence of five main steps, often referred to as basis path testing. It uses the concept of cyclomatic complexity to identify a manageable number of necessary test cases. The steps are discussed below:

Step 1: Understand the Code

• Decision points (if, else, switch, loops)
• Entry and exit points

Step 2: Create the Control Flow Graph

Construct a CFG by converting the code logic into a graphical form showing all possible flows. Here, nodes represent sequential statements or process blocks, and edges (arrows) represent the flow of control.

Step 3: Calculate Cyclomatic Complexity

V(G)=E-N+2P

Step 4: Identify All Independent Paths

Once CC is calculated, a set of independent paths (basis set) is identified. Each path in the basis set contains at least one new edge that previous paths have not traversed. The number of these independent paths will equal the calculated cyclomatic complexity.

Step 5: Design Test Cases

Finally, design and write test cases that force the program to execute each independent path using input data that ensures the program follows a specific execution sequence. This step ensures full branch coverage and thorough testing of the code’s logic.

Path Testing Examples

Here are some examples of path testing that include simple if and if-else statements.

Example 1: Single If Condition

Consider the following source code:

if (x > 0) {
  y = x + 1;
}

y = y * 2;

The CFG for the above code is given as follows:

• Path 1: x > 0 is true → execute if block
• Path 2: x > 0 is false → skip if block

Now, with these paths, let us design test cases as follows:

From this example, it is clear that even a simple program has multiple paths that must be tested.

Example 2: If-else Condition

if Amount > 1000 {
  Discount = 10;
} else
  Discount = 5
endif

print(Price)

1. Control Flow Graph: A CFG for the above code is shown below:
   
   As seen in the diagram, there is a decision point for the IF condition, with two possible branches leading to the final print (Price) statement.
2. Cyclomatic Complexity: For this simple structure, the complexity is 2, indicating two independent paths. (CC = Number of decision points + 1)
3. Identify Paths: From the CFG, we can identify the following paths:
   1. Path 1: Amount > 1000 (True condition) → Apply Discount → Print Price
   2. Path 2: Amount <= 1000 (False condition) → No Discount → Print Price
4. Design Test Cases: From the paths, we can determine the following test cases for the code:
   1. Test Case 1 (Path 1):
      • Input: Amount = 1200
      • Expected Output: Discount = 10; Final Price (e.g., 1200 – 10)
   2. Test Case 2 (Path 2):
      • Input: Amount = 80
      • Expected Output: Discount = 5; Final Price (e.g., 80 – 5)

Hence, by thoroughly testing these two paths, every statement and branch (if-else) in the code is executed at least once, ensuring complete coverage of the logic.

Limitations of Path Testing

• Not Scalable for Large Programs: As the size and complexity of software systems increase, the number of possible paths becomes extremely high. It is not feasible to test every path, leading to gaps in coverage.
• Requires Strong Programming Knowledge: Path testing is a white-box testing method that requires testers to have strong programming knowledge, enabling them to understand the internal code logic.
• Impractical for Infinite Paths: Programming constructs like loops and recursion may give rise to infinite combinations and paths. In this scenario, it is impractical to use path testing.
• Time-consuming: Designing and maintaining path tests can prove to be very costly.
• Maintenance Overhead: With the growing complexity of software and frequent updates to existing systems, maintaining test cases is a significant challenge.
• Limited Focus on Data Flow: Path testing examines control flow and may overlook data flow issues, which can lead to hidden bugs related to how data is handled.

Best Practices for Path Testing

• Focus only on independent paths, not all possible paths.
• Use cyclomatic complexity to limit the scope of testing.
• Automate path testing to save on time and other resources.
• Perform path testing only for critical modules.
• Try to avoid excessive loop path combinations.

Conclusion

Path testing is a powerful white-box testing method that validates all possible execution paths within a program. Path testing analyzes the control flow, identifies independent paths, and designs targeted test cases to ensure comprehensive coverage. This helps to uncover logical errors that may otherwise have been overlooked.

Although path testing is not feasible for large complex applications, performing path testing on selective components can significantly improve the software quality and reliability. It also becomes an essential part of a robust testing strategy when combined with other types of testing.

Hence, understanding path testing not only makes you a better tester but also helps developers write cleaner, more maintainable, and error-free code.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT