To be confident about the correctness of our code requires testing each and every possible execution path.

This process is known as path coverage testing. 

• It requires a unique set of test data for each possible path; Fig 6.3 shows a single path through a typical algorithm. 
• Each binary selection statement creates two possible paths; if our code contains two binary selection statements we would have a maximum of four possible paths. 
• A module of code containing five binary selections would have a maximum of thirty two paths. 
• The number of test data sets required increases exponentially for each extra condition within the code. 
• At first glance we would say it doubles for each extra condition; however nested control structures reduce this situation somewhat. 
• For example a binary selection containing one other nested binary selection actually has three possible paths rather than four.

Even in small software products the number of paths can soon run into the hundreds or even thousands. Large products can often require millions of sets of test data. Repetition structures often have an unknown number of paths so in reality the number would be far greater than even this! Fortunately, there are testing CASE tools available to assist when creating test data and checking code. When checking algorithms the situation is more difficult.

Compromises are often made to reduce the number of test data sets required. The best way to reduce the total number of pathways is to test each subroutine independently. If subroutines have been written as self contained units then each can be tested in the knowledge that it does not effect the processing within other subroutines. The topdown design of the program can be used as a template when designing testing procedures. Bottom-up testing involves testing the lowest level subroutines first and progressively working upwards to the main program. A small driver routine is created to call the subroutine currently being tested. Top-down testing commences with the main program and works down through the hierarchy to the lowest level modules. A stub is required to take the place of each lower level subroutine.

It is normal practice to check post-test iterations using data that causes the body to execute once and more than once. For pre-test repetition, data should be included to cause the body of the loop to execute zero and more than zero times