4.7 Testing and Debugging | 191Desk checking can be done by an individual, but most sizable applications are devel-
oped by teamsof programmers. Two extensions of desk checking that are used
effectively by programming teams are the design or code walk-throughand the
code inspection. The intention of these formal team activities is to move the re-
sponsibility for uncovering bugs from the individual programmer to the group.
Because testing is time-consuming and errors cost more the later they are dis-
covered, the goal is to identify errors before testing begins.
In awalk-through, the team performs a manual simulation of the design or
code with sample test inputs, keeping track of the code’s data by hand. Unlike
thorough testing, the walk-through is not intended to simulate all possible test
cases. Instead, its purpose is to stimulate discussion about the way the pro-
grammer chose to design or implement the code’s requirements.
At an inspection, a reader (typically not the code’s author) goes through the
design or code line by line. Inspection participants point out errors, which are
recorded on an inspection report. Some errors are uncovered just by the process
of reading aloud. Others may have been noted by team members during their
preinspection preparation. As with the walk-through, the chief benefit of the
team meeting is the discussion that takes place among team members. This interaction
among programmers, testers, and other team members can uncover many errors long be-
fore the formal testing stage begins.
At the high-level design stage, the design should be compared to the application re-
quirements to confirm that all required responsibilities have been included and that this
application or class correctly “interfaces” with other software in the system. At the low-
level design stage, when the design has been filled out with more details, it should be
reinspected before its implementation begins.
After the code is written, you should go over it line by line to verify that you’ve faith-
fully reproduced the algorithm—a process known as a code walk-through.In a team-pro-
gramming situation, you could ask other team members to walk through the algorithm
and code with you, to double-check the design and code.
You also should take some actual values and hand-calculate what the output should
be by doing an execution trace(or hand trace). When the code is executed, you can use these
same values as input and check the results. The computer is a very literal device—it does
exactly what we tell it to do, which may or may not be what we want it to do. To make sure
that our code does what we want, we trace the execution of the statements.
When code contains branches, it’s a good idea to retrace its execution using different
input data so that each branch is traced at least once. In the next section, we describe how
to develop data sets that test each branch.
To test an application or method with branches, we need to execute each branch at least
once and verify the results. For example, theconstructorof the classNameincludes a nested
ifstatement that selects among three possible conditions. Overall, the application thus
executes three different sections of code depending on the values in its score arguments.
Walk-through A verification
method in which a team
performs a manual simulation of
the code or design
Inspection A verification
method in which one member
of a team reads the code or de-
sign line by line and the other
team members point out errors
Execution trace Going
through the code with actual
values, recording the state of the
variables