Test Driven Development By Example: Book Review
Date: 2008-10-07 23:17:19

== The Book

http://www.amazon.co.uk/Test-Driven-Development-Addison-Wesley-signature/dp/0321146530/ref=sr_1_1?ie=UTF8&s=books&qid=1223291752&sr=8-1[Test Driven Development by Example] by http://en.wikipedia.org/wiki/Kent_Beck[Kent Beck]

== The Review

I know this book is quite old but I haven't read it before - it's been recommended to me several times but I never got round to reading it, possibly because of my somewhat misguided opinion that seeing as I do TDD nearly every day I shouldn't need to read it.

More by chance than anything else, I was browsing through a http://dahliabock.wordpress.com/[friend's] copy of the book and came across several gems of information which persuaded me that I should take the time to read the rest of it.

== What did I want to learn?

I have worked in a TDD way for over 2 years now so what I hoped to gain from my reading of this book was more reinforcement - I don't need to be persuaded by the author that TDD is a very effective approach to software development and I have a reasonable grasp of the basics.

* What parts of TDD have I forgotten?
* What patterns are there when TDDing?
* How closely will the lessons here link to those from http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/[Clean Code]?
* What will I learn to allow me to use TDD more effectively?

== What did I learn?

* What stood out for me throughout the examples presented in this book was Kent Beck's approach to *keeping the green bar*. Suggestions such as always being+++<strong>+++one change away from a green bar+++</strong>+++ and implementing code in whatever way makes us reach the green bar faster before refactoring it were new to me. I am often guilty of trying to make too many changes at once so this was a good reminder to take small steps and keep the tests running frequently.
* Kent described the purpose of TDD as "*closing the gap between decision and feedback*". At a high level this is in fact what it's all about and is something I forget when I'm deeply entrenched in the code. Getting faster feedback is certainly an important thing to aim for when using TDD.
* One of the things which surprised me about this book was that the pattern being followed to make tests pass involved first of all writing code that was not perfect but which passed the test. Uncle Bob pointed out this same approach in Clean Code - *write dirty code than clean it*. While I think this approach certainly makes sense in theory, I think in practice it requires great discipline (especially when time pressures are involved) to go back and clean up the code every time. Perhaps there is some balance to be found between making the tests pass and writing a reasonably good solution first time around.
* Another interesting approach recommended was to *write initial tests which are concerned with implementation and then refactor* those into ones which test externally visible behaviour. I have certainly been maybe over dogmatic in wanting to only write tests for behaviour of classes, which often makes it difficult to actually get started. This approach could certainly be useful as one to just get something running.
* The *Green Bar Patterns* were new to me - these describe ways to get a test to pass. Kent lists three of them:
 ** Fake It - Just put any value in to make the test pass
 ** Obvious Implementation - Just implement the simple operation
 ** Triangulate - Abstract only when there are two or more examples

+
I have used the first two approaches before (without knowing they had a name) but have never known when each one is appropriate or whether I'm just being annoying to my pair by using 'Fake It'. The ideas given around these in the book give me a slightly better idea.
* Kent keeps a *to-do list* throughout the examples - he often speaks of avoiding distraction from the current test by simply adding new tests or ideas onto the list and looking at them after the current task is complete. I sometimes find myself going off and trying new ideas before finishing the current one so hopefully using this approach will allow me to remain more focused.
* Another thing I often wonder with TDD is how big our steps should be - Kent describes TDD as '*a steering process - a little this way, a little that way. there is no right size*'. To paraphrase - steps of different sizes can be used and we should vary these depending on the situation. If the steps feel too small, make them bigger, and if they feel too big, make them smaller.

== In Summary

I think this is certainly a good book for learning how to do TDD - the examples are very easy to follow and the benefit of different facets of the approach are explained with each test & code change.

Even if you have been doing TDD for a while it is still good to get a reminder of the principles behind it and remind yourself of some of the simple tricks that can make the approach even more effective.