"Test Driven Development" (TDD) is a software development methodology that greatly improves code quality and software development productivity. This sequence of posts intends to cover the basic concepts of TDD, by taking excerpts from the Book:

"Growing Object-Oriented Software, Guided by Tests"
by Steve Freeman and Nat Pryce
(published by Addison Wesley)
http://my.safaribooksonline.com/97803215...


[and Yes: taking excerpts from a book for the purpose of comments and criticism is Fair Use under US Copyright Laws
http://www.copyright.gov/title17/92chap1... ]


TDD in a Nutshell

The cycle at the heart of TDD is:

* Write a test
* Write some code to get the test to pass
* Refactor the code to be as simple an implementation of the tested featurs as possible
* Repeat


As illustrated in the figure

http://en.wikipedia.org/wiki/File:Test-d...

Tests provide feedback regarding

* Does the system work ?
* Is it well structured ?



By writing the Test first, we get double the benefit.
The Exercise of Writing the Tests :

* Makes us clarify the acceptance criteria for the next piece of work - we have to ask ourselves how we can tell when we are done (design)
* Encourages us to write loosely coupled components, so they can easily be tested in isolation and, at higher levels, combined together (design)
* Adds an executable description of what the code does (design)


Whereas Running the Tests :

* Detects errors while the context is fresh in our mind (implementation)
* Let us know when we've done enough, discouraging "gold plating" and unnecessary features (design)



This feedback cycle can be summed up by the Golden Rule of TDD:

"Never write new functionality without a failing test"