Having recently watched Kent Beck’s Test-Driven Development Design (TDD) screen casts available for purchase from the pragmatic programmer website, I must confess I’ve been converted.
I have been writing unit tests for a few years now, and prior to NUnit supporting .NET 2.0 I wrote my own unit test framework, a simple Test Runner which used attributes and reflection to identify and execute tests, an NUnit like GUI, and a static Assert class. I saw unit tests as a good means of asserting the correctness of code, of preventing the introduction of bugs during code changes, and an excellent means of documentation. Furthermore, it forces you to make incremental changes during refactoring and provides constant feedback during the change process. All good stuff.
Despite the benefits, I had two problems with TDD.
Firstly, I misunderstood it. I think it should be renamed Test Driven Design to emphasize that it really drives the design of your code. This is the crucial point that, somehow, I had missed. I had heard that it drives design, but I was not listening.
Secondly, it felt like a lot of rework. Not only did I need to keep re-coding classes, I had to keep re-working the tests. It was whilst watching Kent Beck working through his examples that I noticed his heavy reliance on refactoring tools. TDD and refactoring tools work together like the hammer and the anvil. You need both. Fortunately in C# there is an excellent plugin from JetBrains called Resharper which makes extracting interfaces, generating method stubs, etc. a piece of cake (a must have tool for C# development).
As mentioned, I’m converted.
Kent Beck begins his screen casts with the following introduction:
Test-Driven Development is designed to make developers take more responsibility for the quality of the code that they write.
It consists of three parts:
- Developers write automated tests as they go
- Tests are written in advance of the code
- Design a little at a time
He then proceeds to illustrate TDD by implementing a simple project, beginning with a high level list of tests he needs to write to code the required functionality.
It’s important to note that at this stage he is focused on objectives, what should this program do? Furthermore, he desires the fastest possible feedback so he picks tests he can quickly implement and build upon.
When writing tests Kent Beck uses very descriptive names for his tests. He likes to write little stories, “Every test should tell a story“. He also advises to be granular to get more accurate feedback. For example, if this is the test he wants:
@Test public void getRetrievesWhatWasPut(){
Tyrant t = new Tyrant();
t.put(key,value);
assertEquals(value, t.get(key));
}
He will break it up into smaller tests first to get the fastest possible feedback. In this example, what if Tyrant isn’t running? With that in mind his first test looks like this:
@Test public void getRetrievesWhatWasPut(){
// Tyrant t = new Tyrant();
// t.put(key,value);
// assertEquals(value, t.get(key));
new Socket(“localhost”, 1978);
}
He then mentions that eventually the tests should be self contained and should start-up Tyrant before executing, but at this stage he doesn’t want to invest time in that. He will do that later, and he adds that to his Todo list so it’s not forgotten. Right now he wants to validate his assumptions based upon his reading of the specifications. This is one of the most important lessons I learned watching Kent Beck, how to proceed in an orderly manner and decide what to invest time in, and when.
It’s one thing to read a book about TDD, it’s another to watch an expert demonstrate his craft, I highly recommend the screencasts to anybody interested in learning more about TDD. Here are the first 10 mins of episodes one and two:
TDD Intro, Episode 1, first 10 minutes, unedited from Kent Beck on Vimeo.
TDD Intro Episode 2, first 10 minutes, unedited from Kent Beck on Vimeo.
