Test Driven Development (TDD) is something that many people talk about but few actually do. A common misconception is that TDD is about writing acceptance tests before developing the code. It’s really more than automated acceptance tests … it’s about using unit tests to drive the development process.
There are several books ( and ), good written tuturials using java  and even a tutorial using Ruby . But I find it’s very difficult to communicate how TDD should feel using the written word. In an attempt to help bridge the gap, I’ve created some screencasts that demonstrate TDD.
What is TDD
Before going further I should explain what is meant by TDD. Kent Beck, who popularised TDD and is generally considered the high guru of TDD and XP, wrote that when writing code do two things: Firstly, add a test, get it to fail, and write code to pass the test, and; Second, Remove duplication. This can be more clearly summarized by the following process:
- Write the test.
- Run the test and watch it fail.
- Write the code.
- Run the automated tests, get the code to pass the test.
The simplicity of the process is very deceptive. In practice it’s requires a great deal of discipline to always start with the tests and not the code. This is especially true if the code is “obvious” or “straight forward”. In reality this is seldom the case.
What you will not find in the Screencasts
Having described what TDD is, I’d like to show you what TDD is. But first, I should outline what you will not find in the screencasts. This series of screencasts (3 in total) are intended to be a very simple demonstration of TDD. In order to achieve that I’ve left out a lot of complexity that you’d ordinarily encounter in software development. In particular the following items are noticeably absent from the screencast:
- Practical value. The class that I build is intentionally very, very simple and as a result has little (if any) practical value.
- Exceptions and exception handling. I’ve not addressed exceptions as part of this series of screencasts. I intend to do some work with exceptions in my next screencasts.
- Database connectivity and related issues. I haven’t used a database as part of my example, and so database interactions are totally absent.
- Mocks, httpUnits or other more advanced testing frameworks. There is clearly fertile ground for further work!
A Cheap Shot
Finally, I came across this image as I wandered the web. I wonder if it’s a sign of things to come?
 Test Driven Development, by Kent Beck
 Test Driven Development in Microsoft .Net, by James W. Newkirk and Alexei A. Vorontsov
 http://xprogramming.com/xpmag/acsBowling.htm, and http://xprogramming.com/xpmag/acsBowlingProcedural.htm