Tools
For all of the unit tests in this book, we have used the ubiquitous JUnit (http://www.junit.org)
library. It is the de facto standard for writing unit tests in Java, with wide industry support and
many add-ons. The Spring Framework uses JUnit for its tests, so there are plenty of excellent
examples available if you want to see how unit tests are created in the wild. You can find the
framework’s tests in the testdirectory of the downloaded release.
Example
We will quickly illustrate an example of a unit test to provide some perspective and to give our
discussions some weight. The Flightclass from Chapter 4 is the perfect candidate for a unit
test, as it doesn’t require external resources and contains business logic statements.
Listing 10-3 is the complete test case for the Flightclass. We begin by using setUp()to
create and initialize an instance of Flight, complete with a single FlightLegbetween two
cities. Having one commonly configured Flightinstance makes each test easier to write
because of the consistency of data across test methods.
As you can see, we like to place each situation being tested inside its own test method.
This technique is different than many of the tests you’ll find in the Spring source code distri-
bution, where you’ll commonly find one test method containing many different actions and
assertions. We believe that tests should run in isolation, so we sacrifice brevity for more
explicit test separation. Another benefit of this type of test method separation is that the risk
of orthogonal code affecting the real method under test is reduced.
Some tests are very simple, testing mere getters or read-only accessor methods. For instance,
Listing 10-1 is verifying that the total cost returned by getTotalCost()happens to be the same
cost specified when the Flightinstance was created. These simple-looking methods are just as
important to test as the seemingly more complicated methods. Not only does it increase the test
coverage, but it is providing a very helpful safety net once the refactoring begins (which will hap-
pen sooner or later).
Listing 10-1.testGetTotalCost Method
public void testGetTotalCost() {
assertEquals(40, flight.getTotalCost());
}Other test methods, like the one shown in Listing 10-2, require more configuration than
is provided by the setUp()method. Here we create test local parameters that are controlled
to give our tests precise outcomes, such as a nonstop FlightLegwith valid start and end times.
Notice that the assertEquals()method calculates the expected value independently from
the startand endobjects set up at the beginning of the test. Why not just use assertEquals
((end.getTime()-start.getTime()), flight.getTotalTravelTime())? The expected value (the
first parameter to the assertEquals()method) should never be calculated from parameters
that participate in the test, in order to ensure the test itself doesn’t modify any data that would
affect its validity.
CHAPTER 10 ■TESTING SPRING MVC APPLICATIONS 285