Even if you have managed to obtain 100% code coverage from your tests, you’re not
necessarily finished writing tests. Code coverage utilities are very helpful, but they cannot
indicate whether you have sufficiently covered the edge cases. For example, they may tell you
if you tested a hypothetical addition()method, but they don’t know if you tried it with nulls,
zeros, negative numbers, or infinity. You must use a combination of code coverage reporting
plus edge case tests to really begin to feel like you have a complete set of tests.When Do I Write Tests?
Another common question when writing tests is “When in the process of building the system
are tests created?” The answer to this depends a lot on what software development methodol-
ogy you subscribe to.
Extreme Programming(http://www.extremeprogramming.org), or XP, was one of the first
methodologies to popularize the Agile (http://agilemanifesto.org) movement. One of XP’s
main tenets is a technique named test-driven development, or TDD. It says that before any
code is created, a unit test must first be written. At a very basic level, this means that if strictly
followed, all code will have corresponding tests. However, if the proponents of TDD are cor-
rect, this technique has much broader implications.- You will always have tests for the system if you create them first.When crunch time
comes, unit tests are often left by the wayside. This can be a dangerous decision, espe-
cially because crunch time is when development is moving the fastest (and thus is at its
most risky). - You will get immediate feedback for all code additions and changes.As software grows
and refactoring becomes more important, the safety net of unit tests is essential. By
writing the test first, you will know instantly whether a refactoring worked and regres-
sion bugs were introduced. - The system design will emerge in the simplest possible form.TDD proponents argue that
because the code is created in response to tests, the system will emerge with only the
code that allows the tests to pass. By focusing on passing tests, the code won’t have a
chance to expand into areas not originally intended or required.
The Rational Unified Process (RUP)merely defines a “construction” phase, where the soft-
ware code and tests are created in no specified order.
Feature Driven Development (FDD) declares that unit testing occurs in the fifth process,
“Build by Feature.” FDD does not define exactly when in the process the unit tests are created,
only that they must be created.
Our personal feelings on the subject are these: Test as early as you can. Although strictly fol-
lowing TDD can be a bit dogmatic, writing tests first really does help to drive a more simple
design (of course, it helps to know where you are going). Writing the tests during software con-
struction—especially at the same time the module under test is being created or updated—is an
excellent idea. We’ve noticed that any initial slowdown in coding velocity is greatly outweighed
by the confidence you will have in the system plus the natural robustness from the tests them-
selves. Bottom line is, don’t delay writing those unit tests.
It’s important to note that the advice to write tests as early as possible is specific to unit
tests. Integration tests are naturally created later in the process, as more pieces of the system
have been built.290 CHAPTER 10 ■TESTING SPRING MVC APPLICATIONS