Java Reference
In-Depth Information
duplication. Developers following this practice have found that test-backed, well-
factored code is, by its very nature, easy and safe to change.
TDD
gives us the confidence
to solve today's problems today and tomorrow's problems tomorrow. Carpe diem!
JUnit best practice: write failing tests first
If you take the TDD development pattern to heart, an interesting thing happens:
before you can write any code,
you must write a test that fails
. Why does it fail?
Because you have not written the code to make it succeed
.
Faced with this situation, most of us begin by writing a simple implementation to
let the test pass. Now that the test succeeds, you could stop and move on to the
next problem. Being a professional, you'd take a few minutes to refactor the imple-
mentation to remove redundancy, clarify intent, and optimize the investment in the
new code. But as long as the test succeeds, technically you've finished.
The end game? If you always test first, you'll never write a line of new code without
a failing test.
Now that we've described the cycle—test, code,
refactor
, (repeat), and ship—of test-
driven development, we show next how testing fits into development overall.
5.4
Testing in the development cycle
Testing occurs at different places and times during the development cycle. We first
introduce a development lifecycle and then use it as a base for deciding what types of
tests are executed when. Figure 5.5 shows a typical development cycle we've used
effectively in both small and large teams.
Figure 5.5 A typical application development lifecycle using the continuous
integration principle
