Programming and Problem Solving with Java

(^314) | Object-Oriented Software Design and Implementation

6.9 Testing and Debugging

In addition to providing a design that is easy to implement, the CRC card process

makes it easy to create an initial test plan. The scenario walk-throughs naturally cor-

respond to test cases in our plan. We simply need to note an example of typical data

and expected results from each walk-through. For example, in the walk-through for dis-

playing an entry, we could write down a set of typical values that the user might en-

ter for a name, and we could specify that the address book must contain the

corresponding entry. We could also indicate what other information we expect to be

returned with the entry.

The scenarios produce a plan that combines aspects of both code and data coverage.

At the level of collaborations, we cover the structure of the code. That is, our test plan nat-

urally covers the pattern of method calls corresponding to the collaborations that imple-

ment each responsibility.

If we think a little bit about the range of values that could be present as arguments in

each call during a scenario walk-through, then we can also include data coverage in our

plan. As you go through a scenario, each time a collaboration invokes a responsibility of

another class, record the range of values that could appear in the arguments, as well as an

example value and its expected result. For example, in walking through the addition of an

entry, we collaborated with methods to create each of the objects contained within the en-

try. In each of these cases, we can also record the range of values that are acceptable and

unacceptable as test cases.

Remember, however, that our CRC cards do not develop the algorithms for the individ-

ual responsibilities. Thus, we must extend the test plan with cases that exercise the paths

found within each responsibility. Once the responsibility algorithms are written, review

the test cases that were recorded during the scenario walk-throughs. In each case, con-

sider whether your knowledge of the algorithm indicates control-flow paths that should be

tested specifically.

It may be easiest to test individual classes with a separate driver application class, as

we did with the Phoneclass. The purpose of the driver is to provide a very simple envi-

ronment that allows us to directly test the methods of a class, explicitly controlling the

argument values that are passed to them. When a class is part of a complex design that

involves many different collaborations, it can be difficult to constrain the testing to just

the one class, and to ensure that errors in other classes do not affect its arguments.

Testing and Debugging Hints

1.Use the design methodologies presented in this chapter to carefully design a

complete OOD solution to a problem before you start writing any Java code.

The design should be sufficiently detailed that converting it to Java becomes

almost a mechanical process.