Java Reference
In-Depth Information
of method
teenName
. We find out that it handles arguments in the range
10..19
—even though
10
is not really a teen. Here is where reliance on the name of a
method for its meaning is a mistake!
So we should be able to fix the error by changing the if-statement to the fol-
lowing one:
if
(k >= 10) {
s= s + teenName(k);
k= 0;
}
Running again, with the same input, we see that the error has been fixed.
Discussion
The main goal of this section is to illustrate the debugging process. But it
teaches another lesson:
Debugging maxim 4.
Deal carefully with
interfaces
.
The specification of a method is the interface between the method and calls
to it. The bugs uncovered in this section were interface bugs: methods were
called with unsuitable arguments.
Interfaces are always a problem. When building a house, baseboard molding
is used where the floor meets the walls to hide the cracks, and quarter-round
molding is often placed on the baseboard molding for the same reason. Plumbing
interfaces are a huge source of wet trouble spots. Roofs leak mostly where the
roof meets a chimney; the interface between these two quite different materials
is hard to get right.
So be extremely careful with interfaces!
14.6
Key concepts
• The cost of testing
. Testing consumes far more time than most people imag-
ine. To reduce the time, follow good programming practices.
• Test case
. A test case is a set of input values that are used in testing a program
unit (method, class, etc.) together with the expected result. Good testing requires
developing a suitable set of test cases. Some people will tell you to develop test
cases before writing the program!
• Exhaustive testing
. Such testing requires testing with every possible test case.
Generally, it is infeasible.
• Blackbox or functional testing
. Such testing requires developing test cases
using only the program specification; the program and its structure is not looked
at.
Search WWH ::
Custom Search