With the common cases out of the way, take a look at the algorithm you are testing and
identify all the branches and decision points. To have a complete set of tests, each branch and
condition that fires the branch must be tested. For instance, if you have a switchstatement,
make sure your tests use values that will exercise each condition of the statement including
the defaultstatement. This also applies to anywhere an exception might be thrown (see
testWrongEndTime()in FlightTest(Listing 10-3) for an example).
Of course, any software other than the most trivial will have numerous branches, excep-
tion cases, and execution paths. To ensure that your tests have exercised all of the potential
situations, you can use special tools to track which code is tested and which code isn’t. These
are called code coverage tools, and they work hand-in-hand with testing frameworks (though
they don’t require them) to give you an idea of how much of the system is actually tested.
Code coverage utilities, such as Clover (http://www.cenqua.com/clover) and EMMA
(http://emma.sourceforge.net), instrument the code under test by wrapping each line and
condition with a flag. These flags are set when the active test actually runs the particular line
of code. When the tests complete, the utilities generate a detailed report of which lines of
source code were exercised by the unit tests. The report, as shown in Figure 10-1, provides
an excellent visual way to see how much of the system is actually tested by your unit and
integration tests.
Figure 10-1.HTML report from Clover
■Tip Spring uses Clover for code coverage, and you can generate and view up-to-the-minute coverage
reports yourself with the Ant build included with the source code.
CHAPTER 10 ■TESTING SPRING MVC APPLICATIONS 289