Well-behaved objects - Objects First with Java: A Practical Introduction Using BlueJ - page 252

Should we wish to add further objects to the fixture at any time, one of the easiest ways is to
select Test Fixture to Object Bench , add further objects to the object bench in the usual way, and
then select Object Bench to Test Fixture. We could also edit the setUp method in the editor and
add further fields directly to the test class.

Test automation is a powerful concept because it makes it more likely that tests will be written
in the first place, and more likely that they will be run and rerun as a program develops. You
should try to get into the habit of starting to write unit tests early in the development of a pro-
ject, and of keeping them up to date as the project progresses. In Chapter 12, we shall return to
the subject of assertions in the context of error handling.

Exercise 7.20 Add further automated tests to your project until you reach a point where you
are reasonably confident of the correct operation of the classes. Use both positive and nega-
tive tests. If you discover any errors, be sure to record tests that guard against recurrence of
these errors in later versions.

In the next section, we look at debugging—the activity that starts when we have noticed the
existence of an error and we need to find and fix it.

7.5 Debugging

Testing is important, and testing well helps uncover the existence of errors. However, testing
alone is not enough. After detecting the existence of an error, we also have to find its cause and
fix it. That's where debugging comes in.

To discuss various approaches to debugging, we use a hypothetical scenario. Imagine that you
have been asked to join an existing project team that is working on an implementation of a soft-
ware calculator (Figure 7.6). You have been drafted in because a key member of the program-
ming team, Hacker T. Largebrain, has just been promoted to a management position on another
project. Before leaving, Hacker assured the team you are joining that his implementation of the
part of the calculator he was responsible for was finished and fully tested. He had even written
some test software to verify that this was the case. You have been asked to take over the class
and simply ensure that it is properly commented prior to integration with the classes being writ-
ten by other members of the team.

The software for the calculator has been carefully designed to separate the user interface from
the calculator logic so that the calculator might be used in different contexts later on. The
first version, which we are looking at here, will run with a graphical user interface, shown in
Figure 7.6. However, in later extensions to the project, it is intended that the same calculator
implementation should be able to run in a web browser or on a mobile device. In preparation for
this, the application has been split into separate classes, most importantly UserInterface , to
implement the graphical user interface, and CalcEngine , to implement the calculation logic.
It is this latter class that Hacker was responsible for. This class should remain unchanged when
the calculator runs with a different user interface.