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!