Kent Beck

A slim, fast paced but thorough read about an extreme form of testing. The book assumes a lot of the reader, however if you are working in an agile or extreme environment this book is recommended.

The simple premise of the bookis to provide an in-depth look at the mechanics of Test-Driven Development (TDD). Also Kent Beck is really quite evangelical of his belief in the technique.

A full contents listing is available.

So what is TDD? Mr Beck lays down two golden rules:- 1) Only write new code if an automated test has failed 2) eliminate duplication.

The implications are that the test in TDD is extremely close to the code. You write an automated test. Then write some code and then run the previous written test against it. If the test fails (red), amend the code with the aim of making the test pass (green). Once the test has passed, refactor the code to remove any duplication in the code. Thus generating a mantra of red/green/refactor.

Developing software in this manner does have implications. There is no room for a formal, high ceremony test structure. The testing is conducted in extremely close proximity to the person writing the code. (Probably is the same person.) The development evenvironment must be sensitive to small changes. Finally the code itself has to be in small, cohesive, loosely coupled components.

A number of benefits are claimed for TDD:- lower defect density, closer collaboration in terms of time between developers, better business relationships due to better software.

Extreme programming (XP) and the Agile movement probably dovetail closely with TDD. Especially as Kent Beck is seen as a guru on XP as well. As with all systems or processes, they can be made out to be panaceas. However having read this book, I would say it looks like hard work. The temptation must exist to cut corners. Prime candidate is the refactoring to remove duplication. Once the test has passed, why recode? A good developer will seek to make the code as clean as possible, whilst still working. TDD, XP and Agile are not euphemisms for sloppy. Only bad workmen write sloppily.

There are three parts to the book. The largest part of the book is taken up with development of a foreign currency converter. This example is in great detail, taking many small steps to demonstrate the process. Part 2 covers more complex issues, focusing on the xUnit framework for automated testing, reflections and complicated logic. Part 3 is concerned with the patterns to write, writing tests in xUnit and further small examples.

The money converter uses JUnit as its test framework. I am not sure which language the object code is written in. (I am a tester after all!) However even I can follow the what is going on in the code. From an overall testing perspective, it is very clear what Mr Beck is trying to get across.

Part2 switches to Python. The logic becomes a lot more complicated, but is still accessible.

As befits a technique predisposed to very close team working, the book style is very conversational. Sometimes you get the feeling that Kent is talking you through the process as you sit tapping on the keyboard. This is fine, but does drone on. Maybe you should paraphrase his advice and read the book in "teeny-weeny steps".

Would this book improve testing? As someone who comes from a more traditional test team, I would like to say no. However, if more code was properly tested as it was written, we might end up with cleaner and more efficient code. Even if the book was given to developers, it might promote a more testing orientated culture at the very least. For this reason alone I have to say that reading this book would improve testing.

Who should buy this book? Developers, testers and anyone with interest in the process of developing software.