Tuesday, April 8, 2008

Thoughts on TDD

Having just gone back and read an old article by Michael Feathers entitled 'Emergent Optimization in Test Driven Design' (found at http://www.objectmentor.com/resources/publishedArticles.html) I have been rethinking the whole test driven development argument.

I first started using a TDD approach a few years ago and quickly realized that (at least for me) the 'test' part of TDD was actually a very nice secondary effect. The real power behind the technique is its ability to allow the programmer to work 'from the outside in' as Michael Feathers puts it - leading to better design. His paper actually focuses on the optimization argument, but for me, the primary effect is that it helps me to design an application from a consumer's perspective, as if I were making a library or API for other programmers' consumption.

Using my design argument, I then thought about the traditional order of development tasks - design comes first, then write the code - so if TDD could be viewed as part of the design process, it might gain more widespread acceptance. One of the things inhibiting the practice of TDD is the old stigma about testing and how some programmers have learned to despise the very idea, often citing time and cost constraints as justification. Wouldn't it be great to change the terminology and eliminate the word 'test'. Then I had a realization - that's probably what the BDD movement was all about.

Up until now, I have largely ignored the BDD thing, but I decided that it's time I take a more serious look at it. So I now return to writing this post having watched Dave Astels' video on Google about behaviour driven design - and yes, this is exactly the intent of BDD. I would like to see this approach to programming become more widely accepted, but I wonder how easy it is to change old habits. The enlightened and inquisitive will probably accept, and indeed move on with these ideas, for the many, I fear nothing will change.

At least I learned a valuable lesson, I need to do more research - I slept on this one for too long!

1 comment:

Paul said...

Hi Andrew,

I'm glad the penny dropped for you on BDD. I first came across the idea at XPDay one year were Dan North presented a workshop. And you are spot on. DBB is about changing the language associated with TDD, and using lanuage which is more focused on design.

Ruby is really great for writing domain specific languages. In a sense your test cases are a design language and your tests are an executable design specification. Rspec uses the DSL capabilities of Ruby to define a DSL that target design specification as it's domain. So words like "should" become part of you specification vocabulary.

Language is important, and I think the change in language with BDD means that the idea of an executable specification can be taken one step further. For example Rspec as been expanded to include a DSL for expressing customer acceptance requirements for user stories. Prior to this, the only way to specify user stories in a verifiable way was with Fit tests. I don't believe that this advancement in Agile practices would have occurred without the change in language.