Java Reference
In-Depth Information
key presses to complete a simple calculation. We might remark that the method is not particu-
larly ambitious—both operands are single-digit numbers, and only a single operator is used.
However, that is not unusual in test methods, because it is important to test for the most basic
functionality before testing more complex combinations. Nevertheless, it is useful to observe
that some more complex tests should be added to the tester at some stage.
Exercise 7.24 Perform a similar walkthrough of your own with the testMinus method.
Does that raise any further questions in your mind about things you might like to check when
looking at CalcEngine in detail?
Before looking at the CalcEngine class, it is worth walking through the testAll method to
see how it uses the testPlus and testMinus methods we have been looking at. From this we
observe the following:
The testAll method is a straight-line sequence of print statements.
It contains one call to each of testPlus and testMinus , and the values they return are
printed out for the user to see. We might note that there is nothing to tell the user what the
results should be. This makes it hard for the user to confirm that the results are correct.
The final statement boldly states:
All tests passed.
but the method contains no tests to establish the truth of this assertion! There really should
be a proper means of establishing both what the result values should be and whether they
have been calculated correctly or not. This is something we should remedy as soon as we
have the chance to get back to the source of this class.
At this stage, we should not be distracted by the final point into making changes that do not
directly address the errors we are looking for. If we make those sorts of changes, we could eas-
ily end up masking the errors. One of the crucial requirements for successful debugging is to be
able to trigger the error you are looking for easily and reproducibly. When that is the case, it is
much easier to assess the effect of an attempted correction.
Having checked over the test class, we are in a position to examine the source of the CalcEngine
class. We can do so armed with a reasonable sequence of method calls to explore from the walk-
through of the testPlus method, as well as with a set of questions thrown up by it.
Checking state with a walkthrough
A CalcEngine object is quite different in style from its tester. This is because the engine is
a completely passive object. It initiates no activity of its own, but simply responds to external
method calls. This is typical of the server style of behavior. Server objects often rely heavily
on their state to determine how they should respond to method calls. This is particularly true of
the calculator engine. So an important part of conducting the walkthrough is to be sure that we
always have an accurate representation of its state. One way to do this on paper is by making
up a table of an object's fields and their values (Figure 7.7). A new line can be entered to keep a
running log of the values following each method call.
Search WWH ::

Custom Search