Why Test-Driven Development?


You will write virtually all code in this book using TDD. TDD is a technique where you specify the system in terms of tests. You write tests prior to (or as) you write the production code; you do not write production code then supply tests after the fact.[5]

[5] [Langr2001].

TDD is a simple, short-cycled mechanism that you repeat throughout your coding day. Each cycle lasts from seconds to minutes, and consists of the following steps:

  • Write a specification, in code and in the form of a unit[6] test.

    [6] The test verifies a functional unit of your code. Another term for unit test is programmer test.

  • Demonstrate test failure (you haven't implemented the specification yet).

  • Write code to meet the specification.

  • Demonstrate test success.

  • "Refactor," or rework the code, to ensure that the system still has an optimally clean code base.

That's it. You run all tests against the entire system at all times, ensuring that no new code breaks anything else in the system.

Tests drive several positive aspects of the system:

  • quality. TDD minimizes the number of defects, since by definition, you test everything in the system. You improve your system's design, since TDD drives you toward more decoupled designsdesigns where classes are not as heavily dependent upon other classes in the system.

  • documentation of capability. Each unit test specifies the appropriate use of a production class.

  • malleability. Having tests in place means that you can continually improve the quality of the code base without fear of breaking something that already works. This can result in lower maintenance costs.

  • consistent pacing. Since each cycle in TDD is very short, feedback levels are high. You quickly discover if you are going down a rat hole. You learn to maintain a very consistent, sustainable rate of development.

An additional benefit of TDD is that it helps demonstrate the examples in this book. You quickly learn how to translate specifications into test code and how to translate test code into production J2SE 5.0 code.

From a developer's standpoint, TDD is infectious.[7] Most developers who give it an honest try retain it as a valuable tool in their development toolbox. Many of the developers I've talked to about TDD, including some seasoned Java pioneers, say that they never want to go back to the "old way" of doing things. I was first exposed to the idea of always writing tests for code in 1996, when I saw Kent Beck speak at a Smalltalk Solutions conference. My personal reaction was "I'm a programmer, not a tester!" Today, I'm amazed at the value it brings me and the amount by which it improves my development capabilities. I wouldn't do it otherwise.

[7] [Beck1998].



Agile Java. Crafting Code with Test-Driven Development
Agile Javaв„ў: Crafting Code with Test-Driven Development
ISBN: 0131482394
EAN: 2147483647
Year: 2003
Pages: 391
Authors: Jeff Langr

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net