<< The September 2007 Caffeinated Codey Winners are... | Home | The Echo Chamber Challenge >>

Taking Another Look at BDD

When I first heard about Behavior Driven Development, I dismissed it as a trivial re-branding of TDD (Test-Driven Development). I figured that either someone was getting way too anal about "getting the words right" or else a concerted effort was being made to make TDD more palatable to the skeptics in the same way that Agile made Extreme Programming principles more mainstream through the magic of less controversial language. It's hard not to be cynical about re-branding efforts when you've had to endure years of corporate culture propaganda and a lifetime of marketing voodoo.
 
Since BDD is one of the topics that will be discussed at the ALT.NET conference that I will be attending this weekend, I decided to challenge my initial assumption and do some verigoogling on the topic. I am pleased to report that I have changed my mind about BDD and now believe that there is enough significant content in this mini-methodology that is beyond the realm of traditional TDD to merit some serious discussion.

If you want a quick introduction into how BDD is different from TDD, I recommend reading the article Introducing BDD by Dan North, who appears to have coined the phrase. He starts by relating the common problems he had as a TDD coach and then describes different evolutions in his thought process and how a fundamental shift in his orientation ultimately helped alleviate these problems. He concluded that the word "test" was partially responsible for students overlooking the critical design-oriented benefits of writing tests first and that changing the focus from an application's state to its behavior naturally led practitioners to more sophisticated and effective TDD practices.

One concrete example of how this different perspective alters the way you write tests has to do with naming. One BDD practice is to name tests using simple sentences that start with Should (i.e. ShouldFailForMissingSurname) and use Ubiquitous Language that your business users would easily understand when choosing the words. This is one of the areas where Domain Driven Design, one of the three pillars of BDD, comes into the mix. Besides allowing tools like NSpec to actually produce usable documenation from your tests, this naturally forces developers to limit the scope of their tests (you can only fit so much into a name), which in turn leads to better design and less debugging with the IDE debugger.
 
If you want to learn more about this practice, I would first suggest perusing Behaviour-driven.org to get a higher level overview and then digging into the blog posts under Scott Belware's BDD Category to get some deeper insight into these practices. Jeremy Miller also has a good post entitled BDD, DDD, and other Double D's.

Print | posted on Wednesday, October 03, 2007 1:03 AM

Comments on this post

No comments posted yet.

Your comment:

 (will show your gravatar)