Previous: 2.3 Testing the Program
Up: 2.3 Testing the Program
Next: 2.3.2 Documenting the Code
Previous Page: 2.3 Testing the Program
Previous: 2.3 Testing the Program
Up: 2.3 Testing the Program
Next: 2.3.2 Documenting the Code
Previous Page: 2.3 Testing the Program
A program may have bugs, i.e. errors, in any of the above phases so these bugs must be removed; a process called debugging. Some bugs are easy to remove; others can be difficult. These bugs may appear at one of three times in testing the program: compile time, link time, and run time.
When a program is compiled, the compiler discovers syntax (grammar) errors, which occur when statements are written incorrectly. These compile time errors are easy to fix since the compiler usually pinpoints them reasonably well. The astute reader may have noticed there are bugs in the program shown in Figure 2.1. When the file pay0.c is compiled on a Unix C compiler, the following message is produced:
"pay0.c", line 21: syntax error at or near variable name "rate_of_pay"This indicates some kind of syntax error was detected in the vicinity of line 21 near the variable name rate_of_pay. On examining the file, we notice that there is a missing semi-colon at the end of the previous statement:
hours_worked = 20.0Inserting the semi-colon and compiling the program again eliminates the syntax error. In another type of error, the linker may not be able to find some of the functions used in the code so the linking process cannot be completed. If we now compile our file pay0.c again, we receive the following message:
/bin/ld: Unsatisfied symbols: prinf (code)It indicates the linker was unable to find the function prinf which must have been used in our code. The linker states which functions are missing so link time errors are also easy to fix. This error is obvious, we didn't mean to use a function, prinf(), but merely misspelled printf() in the statement
prinf("Pay = %f\n", pay);
Fixing this error and compiling the program again,
we can successfully compile and link the program, yielding an executable
file.
As you gain experience, you will be able to arrive at a program free of
compile time and link time errors in relatively few iterations of
editing and compiling the program, maybe even one or two attempts.
A program that successfully compiles to an executable does not necessarily mean all bugs have been removed. Those remaining may be detected at run time; i.e. when the program is executed and may be of two types: computation errors and logic errors. An example of the former is an attempt to divide by zero. Once these are detected, they are relatively easy to fix. The more difficult errors to find and correct are program logic errors, i.e. a program does not perform its intended task correctly. Some logic errors are obvious immediately upon running the program; the results produced by the program are wrong so the statement that generates those results is suspect. Others may not be discovered for a long time especially in complex programs where logic errors may be hard to discover and fix. Often a complex program is accepted as correct if it works correctly for a set of well chosen data; however, it is very difficult to prove that such a program is correct in all possible situations. As a result, programmers take steps to try to avoid logic errors in their code. These techniques include, but are not limited to:
As we have stated,
and will continue to state throughout this text,
careful design of of the algorithm is perhaps the most important
step in programming.
Developing and refining the algorithm using tools such as the structural
diagram and flow chart discussed in Chapter before any
coding helps the programmer get a clear picture of the problem
being solved and the method used for the solution.
It also makes you think about what must be done before worrying about
how to do it.
Breaking a task into smaller pieces helps both at the algorithm design stage and at the debugging stage of program development. At the algorithm design stage, the modular approach allows the programmer to concentrate on the overall meaning of what operations are being done rather than the details of each operation. When each of the major steps are then broken down into smaller steps, again the programmer can concentrate on one particular part of the algorithm at a time without worrying about how other steps will be done.
At debug time, this modular approach allows for quick and easy localization of errors. When the code is organized in the modules defined for the algorithm, when an error does occur, the programmer can think in terms of what the modules are doing (not how) to determine the most likely place where something is going wrong. Once a particular module is identified, the same refinement techniques can be used to further isolate the source of the trouble without considering all the other code in other modules.
Just as proper algorithm design and modular organization can speed up the debugging process, incremental implementation and testing can assist in program development. There are two approaches to this technique. The first is to develop the program from simpler instances of the task to more complex tasks as we are doing for the payroll problem in this chapter. The idea is to implement and test a simplified program and then add more complicated features until the full specification of the task is satisfied. Thus beginning from a version of the program known to be working correctly (or at least thoroughly tested), when new features are added and errors occur, the location of the errors can be localized to added code.
The second approach to incremental testing stems from the modular design of the code. Each module defined in the design can be implemented and tested independently so that there is high confidence that each module is performing correctly. Then when the modules are integrated together for the final program, when errors occur, again only the added code need be considered to find and correct them.
Another useful technique for debugging programs begins after the program
is coded, but before it is compiled and run, and is called a
program trace.
Here the operations in each statement of the program
are verified by the programmer.
In essence, the programmer is executing the program manually using
pencil and paper to keep track changes to key variables.
Diagrams of variable allocation such as those shown in
Figures 2.2---2.4 may be used for this manual trace.
Another way of manually tracing a program is shown in Figure 2.5.
Here the changes in variables is seen associated with the statement
which caused that change.
Program traces are also useful later in the debug phase. When an error is detected, a selective manual trace of a portion or module of a program can be very instrumental in pinpointing the problem. One word of caution about manual traces - care must be taken to update the variables in the trace according to the statement as written in the program, not according to the intention of the programmer as to what that statement should do.
Manual traces can become very complicated and tedious (one rarely traces an entire program), however selective application of this technique is a valuable debugging tool. Later in this chapter we will discuss how the computer itself can assist us in generating traces of a program.