BDD and the Power of Metaphor

I read an interesting article by "Uncle" Bob Martin talking about Behaviour Driven Development (BDD). Since I hadn't heard of it before, I decided to scratch the surface and see what I could find. One of the nuggets I found was a PDF by Dave Astels expressing his frustration about how no one seems to get Test Driven Development (TDD) right:

"Everyone who's doing TDD is fully understanding it and getting the full benefit, right? Fat Chance! Too few people I talk to really understand what it's really about. That means that many people who practice TDD are not getting the full benefit from it."
...
"The thing is, when the evolution to TDD happened what we ended up with was a different kind of animal... not just a slight tweak on the original."
...
"So, there you have it. A fabulous idea... wrapped in packaging that causes people to think from a testing point of view."
...
"So if it's not about testing, what's it about? It's about figuring out what you are trying to do before you run off half-cocked to try to do it."

Digging a little deeper, it turns out that Dan North has been having these ideas for a while and he writes a nice introduction to behaviour-driven development. I recommend it highly, as it clearly lays out the motivation for BDD. This introduction to BDD is also a good place to start.
Basically, BDD is taking TDD closer to specifications rather than tests. Well, executable specifications, so they remain tests, just look and sound more like specifications. In essence, it's not really a new technique per se, but a new way of thinking about, designing, and organizing tests.

What I find interesting is that one of the main motivations is 'getting the words right', which is exactly what I was thinking when I wrote a blog called "Why Are Continuations So Confusing, and What Do They Really Do?". My gripe was that the word 'continuation' doesn't actually help you to understand what a continuation really is, and I proposed thinking instead in terms of 'execution sites'. For me, that metaphor works much better, just as the metaphor of specifying behaviour is better than the metaphor of unit testing.

Metaphor and analogy are powerful tools of understanding and insight, if you can find a useful connection. Earlier this week I blogged about the connection shared by TDD and continuous integration (CI), showing that they are both part of the same agile trend towards faster and faster feedback on quality (TDD at the programmer-level and CI at the team-level). Now with this whole BDD thing, I wonder what kinds of insights and connections BDD can bring to CI and vice versa. Maybe part of the job of developing TeamCity will be to develop a new vocabulary for continuous integration.