Debugging by Thinking

8.1 I Review 217

8.11

If you want to choose as a hypothesis that the problem is one that the

programmer makes frequently, you need records on the root causes of previ-

ous defects diagnosed in the system in question. If you want to choose as a

hypothesis that the problem is one of the most common errors made when

using the particular programming language selected for this application,

consult an error checklist from a programming text, or Appendix A.

If you want to choose as a hypothesis that the problem is one of the

most common errors made by all programmers, you might find it useful to

consult Chapter 11. If you want to choose as a hypothesis that the problem

is in recently changed code, you need to have been using a source control

system.

Review

Debugging heuristics don't lend themselves to easy categorization, as strate-

gies and tactics do.

The first heuristic to apply is often called

stabilizing the problem.

The

goal of stabilization is reproducibility. The first step in stabilizing a program

is to obtain an undesired behavior each time the program executes. The

next step is to obtain the same undesired behavior each time the program

executes. The third step is to obtain the same undesired behavior in differ-

ent environments. The fourth step is to obtain the same undesired behavior

on different platforms.

The second heuristic to apply is to create a standalone test case. A test

case typically has two parts: the program and the input data. We present

heuristics for creating test case programs and test input data.

To cut down a file-oriented application into a standalone test, create a

file that contains the inputs required to get the program just prior to the

point where the problem occurs. Insert a call to record the program state

just prior to the problem. Run the program with the log file, capture the

program state, build a new driver that sets that state directly, and replace the

old driver with the new one.

To cut down a GUI application into a standalone test, create a log that

contains the mouse and keyboard actions required to get the program just

prior to the point where the problem occurs. Insert a call to record the pro-

gram state just prior to the problem. Run the program with the log file,

capture the program state, build a new driver that sets that state directly,

and replace the old driver with the new one.

I Chapter 8