Caffeinated Coder

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.

Finally, the moment has arrived that you’ve all been anxiously awaiting. Welcome to the 3rd monthly installment of the Caffeinated Codey awards where I recognize some of my favorite posts from the past month. As always, the lucky winners will receive a caffeinated or alcoholic beverage of their choice if we should ever meet.

This month’s winners are…

1. For Most Likely to Incite a Violent PETA Riot…Justice Gray for his post Javascript raped my dog, and other falsehoods. It seems barely a day goes by without reading about some accusation of bestiality involving a scripting language and a common household pet. Justice goes out on a limb to valiantly defend javascript from its decidedly un-metrosexual detractors.
2. For Best Open Source Marketing Strategy…Roy Osherove for his post Do you like Boobs?. Despite never having used it, I have inexplicably positive sentiments towards Boobs, the new Boo Build System that was inspired by Rake.
3. For Taking Passion for his Work to the Next Level…Ayende Rahien for his post NHibernate is female. It’s easy enough to justify referring to your development tools as feminine when you cite linguistic and cultural explanations, but what about when you fantasize about your ORM tool in a french maid outfit, fish-net stockings, and 5 inch stiletto heels? Come on, I know I’m not the only one who has done this…
4. For Best Illustration of Iterative Development…Martin Fowler for his post on RollerSkateImplementation. It is so true that the key to successful iterative development is a good imagination. I don’t know how many times I’ve thought or heard someone say that it was impossible to break up a certain piece of functionality only to later discover a creative way that involves some combination of temporary manual interventions. If Agile had a logo, it should be roller skates.
5. For Best TMI (Too Much Information) Moment…Phil Haack for his post Last Night A Doctor Saved My Nut. In case you don’t wince enough at Phil’s medical explanation of testicular torsion or his account of the doctor violently untwisting his testicle, he provides an illustrative photo of a very large cracked nut to drive home the point. Ouch…
6. For Most Likely to Stick to the Roof of your Mouth… Jeff Atwood for his post Peanut Butter Theory of User Interface Design. Jeff’s post will convince you that you shouldn’t spread the interface over a system like peanut butter in the final stages of development if you want to your application to be truly usable. It might also inspire you to make a good old fashioned PB&J sandwich with the edges cut off the bread.
   
7. For Best Way to Explain Software Maintainability to your Mom…Chris Holmes for his post Selling Maintainability. Chris makes a compelling argument that it is more helpful to think of software as a garden than a finished project in order to convey the reality and importance of maintainability to users. Finally, you can explain what the hell you do to your mom.
   
8. For Best Way to Explain Software Maintainability to your Drinking Buddy…Evan Hoff for his post Off-the-Shelf RAD is for Pimps, Hookers, and Johns–not Marriage. Evan talks about the evils of RAD (Rapid Application Development) tools, wizards, and drag-and-drop components that make for great demos and are perfect for Little League applications, but lead to maintenance nightmares that will leave your Enterprise applications with the software equivalent of flesh eating STD’s (sexually transmitted diseases). Try this as a conversation starter with your friends after a round of Jack Daniels shots.
   
9. For Best Literary Reference…Jeremy Miller for his post Having a Captain Ahab Moment. Jeremy provides the perfect literary reference to describe how easy it is for developers to fall into a thrashing mode and spend inordinate amounts of time on relatively unimportant tasks as a result of taking it too personally when something doesn’t work the way it should. Too bad that not many developers have actually read Moby Dick.
10. For Best Language Evangelism… Scott Bellware for his post on Ruby Makes You a Better Person. I knew that you could speed up development time, produce elegant code, cure cancer, and achieve world peace with Ruby, but I had no idea that it could also improve my spiritual well-being. I bet it took forever to implement that feature.
    

Once again, congratulations to all the winners. Hopefully we’ll meet someday so you can claim your prize. In case you’ve missed the prior award ceremonies, here are the winners from July and August.