Kent Beck's Test Driven Development Screencasts
Following the recommendations of Corey Haines, Michael Guterl, James Martin and Michael Hunger I decided to get Kent Beck’s screencasts on Test Driven Development which have been published by the Pragmatic Programmers.
I read Kent’s ‘Test Driven Development By Example’ book a couple of years ago and remember enjoying that so I was intrigued as to what it would be like to see some of those ideas put into practice in real time.
As I expected a lot of Kent’s approach wasn’t that surprising to me but there were a few things which stood out:
The goal seemed to be to keep the feedback loop as tight as possible and this was approach was the easiest way to achieve that when starting out.
I’m still unsure about this practice because although Ian Cartwright points out the dangers of doing this it does seem to make for better pairing sessions. The navigator doesn’t have to wait twiddling their thumbs while their pair types out what is probably a fairly similar test to one of the others in the same file. Having said that it could be argued that if your tests are that similar then perhaps there’s a better way to write them.
For me the main benefit of not copy/pasting is that it puts us in a mindset where we have to think about the next test that we’re going to write. I got the impression that Kent was doing that anyway so it’s probably not such a big deal.
To use Esko Luontola’s lingo I think the tests follow the specification style as each of them seems to describe a particular behaviour for part of the API.
I found it interesting that he includes the method name as part of the test name. For some reason I’ve tried to avoid doing this and often end up with really verbose test names when a more concise name with the method name included would have been way more readable.
A couple of examples are ‘getRetrievesWhatWasPut’ and ‘getReturnsNullIfKeyNotFound’ which both describe the intent of their test clearly and concisely. The code and tests are available to download from the Prag Prog website.
He described the following algorithm to help find the best order:
I’m not sure if Kent intended for that cycle to be followed just when practicing or if it’s something he’d do with real code too. An interesting idea either way and since I haven’t ever used that technique I’m intrigued as to how it would impact the way code evolved.
Overall it was an interesting series of videos to watch and there were certainly some good reminders and ideas for doing TDD more effectively.