5.4 Testing and Debugging | 253guidelines that are specific to loops. In general, the goal of testing a loop is to verify that
it behaves as expected.
Unfortunately, when a loop is embedded in a larger application, it sometimes is difficult
to control and observe the conditions under which the loop executes using test data and out-
put alone. In some cases we must use indirect tests. For example, if a loop reads floating-point
values from a file and prints their average without echo-printing them, you cannot tell di-
rectly that the loop processes all of the data. If the data values in the file are all the same, for
example, then the average will appear correct if even one of them is processed.You must con-
struct the input file so that the average is a unique value that can be arrived at only by pro-
cessing all the data.
To simplify our testing of such loops, we would like to observe the values of the vari-
ables involved in the loop at the start of each iteration. How can we observe the values of
variables while an application is running? Two common techniques are the use of the
system’s debuggerapplication and the use of extra output statements designed solely for
debugging purposes. We discuss these techniques in Testing and Debugging Hints.
Now let’s look at some test cases that are specific to the different types of loops that
we’ve examined in this chapter.
Count-Controlled Loops When a loop is count-controlled, you should include a test case that spec-
ifies the output for all the iterations. It may help to add an extra column to the test plan that
lists the iteration number. If the loop reads data and outputs a result, then each input value
should produce a different output to make it easier to spot errors. For example, in a loop that
is supposed to read and print 100 data values, it is easier to tell that the loop executes the cor-
rect number of iterations when the values are 1, 2, 3... , 100 than if they are all the same.
If the application takes as input the iteration count for the loop, you need to test the
cases in which the count is invalid. For example, when a negative number is input, an er-
ror message should be output and the loop should be skipped. You should also test vari-
ous valid cases. When a count of 0 is input, the loop should be skipped; when a count of
1 is input, the loop should execute once; and when some typical number of iterations is
input, the loop should execute the specified number of times.
Event-Controlled Loops In an event-controlled loop, you should test the situation in which
the event occurs before the loop, in the first iteration, and in a typical number of iterations.
For example, if the event is that EOF occurs, then try an empty file, a file containing one
data set, and another containing several data sets. If your testing involves reading from
test files, you should attach printed copies of the files to the test plan and identify each
in some way so that the plan can refer to them. It also helps to identify where each iter-
ation begins in the Input and Expected Output columns of the test plan.
When the event is the input of a sentinel value, you need the following test cases:
1.The sentinel is the only data set.
2.The sentinel follows one data set.
3.The sentinel follows a typical number of data sets.