Java Reference
In-Depth Information
calculation, our confidence in it is strengthened. If the manual results differ from
the program results, we have a starting point for the debugging process.
You should calculate test cases by hand to double-check that your application
computes the correct answer.
Surprisingly, many programmers are reluctant to perform any manual calculations
as soon as a program carries out the slightest bit of algebra. Their math phobia
kicks in, and they irrationally hope that they can avoid the algebra and beat the
program into submission by random tinkering, such as rearranging the
+
and
-
signs. Random tinkering is always a great time sink, but it rarely leads to useful
results.
Let's have another look at the
TaxReturn
class. Suppose a single taxpayer earns
$50,000. The rules in
Table 1
state that the first $21,450 are taxed at 15%. Expect
to take out your calculatorȌreal world numbers are usually nasty. Compute
21,450 ¶ 0.15 = 3,217.50. Next, since $50,000 is less than the upper limit of the
second bracket, the entire amount above $21,450, is taxed at 28%. That is
(50,000-21,450) ¶ 0.28 = 7,994. The total tax is the sum, 3,217.50 + 7,994 =
11,211.50. Now, that wasn't so hard.
Run the program and compare the results. Because the results match, we have an
increased confidence in the correctness of the program.
It is even better to make manual calculations before writing the program. Doing so
helps you understand the task at hand, and you will be able to implement your
solution more quickly.
213
214
Q
UALITY
T
IP
5.4: Prepare Test Cases Ahead of Time
Let us consider how we can test the tax computation program. Of course, we
cannot try out all possible inputs of filing status and income level. Even if we
could, there would be no point in trying them all. If the program correctly
computes one or two tax amounts in a given bracket, then we have a good reason
to believe that all amounts within that bracket will be correct. We want to aim for
complete coverage of all cases.
