Test-Driven Development (By Example) - Kent Beck

Kent Beck demonstrates the testing side of XP by separating it out into its own simple methodology. Test-Driven Development is exactly what it says it is. The entire design and development effort is driven by the tests that you write and you’re encouraged to write those tests first…

Parts one and two contain worked examples of Test-Driven Development. Some will probably say that they’re too simple, but I’ve found that even the most complex domain usually ends up as relatively simple code if you develop in this way. It needs to be simple to be testable. One of the major advantages of writing tests as you write code is that you are forced to actually use your code very early on. If the interface is complex and hard to test then it’s probably also hard to use; as you simplify to make the code easier to test you improve the design of the API itself.

As someone who develops in this style, albeit with far less tests than I should have and often by taking far larger steps than shown in the book, what I found interesting was the way the design converged on something that was ‘right’ as the code and understanding grew; this is definitely true to reality. I think, perhaps, that some people may find the coding steps shown in the book too small and this may put them off. It may have been worth trying to take far larger steps initially and then cut them down to size as the difficulty in taking larger steps became apparant. Although Kent makes it clear that you can take larger steps and write more code as your confidence grows I find that what usually works best is just to ‘walk faster’ in smaller steps.

My one complaint with this book would be that unless you’ve programmed in this style before it’s probably not obvious exactly how fast it’s possible to go whilst taking such small coding steps. Although there are some graphs of time taken between test runs and number of lines changed per refactoring these possibly don’t help make it clear that the worked example is probably less than a day’s work in all. I think it would have been handy to have some timestamps at each change to show just how quickly things can happen.

Part 3 of the book contains details of some patterns that are useful in Test-Driven Development. Things like Mock Object and Self Shunt are great tools when testing and once you’ve discovered the power of being able to plug in mock up versions of your code’s dependencies to enable testing your designs will change forever. The result being loosely coupled objects that are easy to test and, as a nice side effect, easy to use and reuse.

A useful and interesting book. If you come away from it feeling that it can’t possibly work, give it a try anyway, you’ll be surprised.