Coming to Terms with Behavior Driven Development
BDD Introduction
Anyhow, there has been a lot of discussion around BDD lately on the altdotnet mailing list around the definition and applicability of BDD in regards to Test Driven Development (TDD). Subsequently, this led to forming a new group on Google Groups about Behavior Driven Development. It's great to see the community start to gain momentum and talk about it more. I've been following Dan North, Joe Ocampo, Scott Bellware, JP Boodhoo and Dave Laribee on this for a while, but now to come to a centralized place for that knowledge sharing has been invaluable. I've seen too many times that there is a high noise to information ratio out there and we need to clarify a few things before it can really take hold.
Getting back to the subject at hand, if you're unfamiliar with BDD, you should check out Dan North's explanation here. There are a good number of links inside to whet your appetite. To put things succinctly, BDD aims to bridge the gap between Domain Driven Design and Test Driven Development.
Dave Astels, also has a great video on Google Video on BDD you can find here. It's a great video which talks about how TDD differs and evolved from BDD. It also delves into the subject of rSpec, the BDD framework in Ruby. Very worth your time to check it out.
Dave's summation of BDD comes down to the following bullet points:
- Don't talk about Units in regards to Unit Testing, instead talk about Behaviors
- All software we write has behaviors
- There should be no correlation between public methods on a class and test classes
- Structure your tests around the behavior of your application
- Put emphasis on behaviors (How do I get it to do what I want it to)
- Get rid of state based testing and look at interactions instead
- Get rid of tests and instead use specifications of behavior (specs)
- Get rid of assertions and instead set up expectations
I agree with Jimmy Bogard, that going to TDD to BDD in one fell swoop by just renaming your tests. Instead, we should focus on those interactions between the systems and less on the physical implementations of the code. We should also focus on the expectations inside our code as well. Mocking and the use of Rhino Mocks or your other mocking framework will do nicely in here. Brian Donahue also has some nice stabs at BDD as well here, here and here. If you're up in the Philly area soon, Brian will be making the rounds doing BDD presentations...
Dave Laribee has also put some thought into BDD as well with a particular set of classes he has written to help with BDD that you can check out here. Also if you've paid attention to the BDD mailing list on Google Groups, you will note that Scott Bellware also has a framework up on Google Code called SpecUnit which is an extension to NUnit to support naming conventions of BDD inside of the xUnit type frameworks. Very cool ideas coming out!
Wrapping It Up
I encourage you to join the BDD list, read the links, and learn more. I find it's a more intuitive way of proving the behavior of your application (Note that I didn't say test). I find that it bridges the gap between Domain Driven Design and Test Driven Development quite handily especially in regard to using the ubiquitous language. It's important that naming and ubiquitous language comes into play when using BDD, because you can share your specs and they should be able to read them as well. It's a great gap between user stories and the code you write. If you need help with user stories, check out Mike Cohn's User Stories Applied book. Anyhow, I hope you found this useful as an introduction to some of my many upcoming BDD posts.
