Niclas Nilsson home

Behaviour-Driven Development - the step after TDD

Sometimes things are moving fast. Dave Astels was scheduled to present Behaviour-Driven Development (BDD) at JAOO this year, but had to cancel. So, who can replace Dave when it comes to talking about BDD? Not many people can really describe the difference between Test-Driven Development and Behaviour-Driven Development in a convincing way yet, but the guy who invented the term BDD certainly can - Dan North.

Dan then somehow lost his mind and invited me to co-present it with him - and now it’s too late for him to change his mind, because now it’s official: We’re going to give “Behaviour Driven Development… the step after TDD” next Wednesday at JAOO 2006. And as if that wasn’t fun enough - it just happens to be part of the Ruby track…

The first time I heard about BDD was at RubyConf last year. It was not an actual presentation at the conference, but more of an improvised presentation at a break. Unfortunately the presentation was probably a bit too unplanned and improvised for the subject, because the message became too simplified. All that I and many others got was more or less “if you just change the word from ‘test’ to ‘should’ in your test cases and people will suddenly understand TDD”. Even though I agree completely about the underlying values of TDD, the presentation made me certain that it was completely useless and confusing to introduce a new term that late in the game (since TDD was really getting a well-known term). And I was sure that it would make no real difference.

A couple of months later at a workshop in Cortina, I met Dan. The workshop had a great open and curious atmosphere and the level of discussions was high, so when Dan and I happened to start chatting after the dinner one night, we started the conversation with “Ah - fun, someone new to talk to! What can we disagree about?”. Dan then started off by saying ”I’ll tell you about Behaviour-Driven Development”. My response, based on my previous experience, was of course “Please, come on - I already know about it and it’s completely useless”. And - yes - the discussion was in full bloom.

The problem was that I lost. Dan’s reasoning about BDD was very different from what I heard before and after a while, I started understanding what he really was trying to accomplish.

First of all, people who are already doing TDD as it is intended already knows that TDD - in spite of the name - is not about testing. There is a very, very nice side-effect to TDD and that is that you get a lots and lots of automated tests, but you can get the exact same benefit by writing your unit-tests after you wrote the production code. However, writing the tests after you write the production code does not (and can not) drive your design the same way that TDD does, and it will not affect the way you think about your software and the way you approach it as TDD does. The resulting production code will not be the same.

BDD helps to avoid this common pitfall. I have to admit that the wording is much more important than I first recognized to accomplish this. The problem is that if you already understand that testing is just one aspect of TDD, then you can not appreciate the new wording properly since you already think about your unit tests as design tools, no matter what they are called. However, you can avoid that other people who hear you speak about Test-Driven Development draws the conclusion that it actually is about testing. The word ‘test’ tends to (for some reason) make people think that it is about tests - and we all know that you can not test something that is not there, so any sane person will think it should be done afterwards (which, again - it shouldn’t). Changing the words does actually help since the word ‘behaviour’ does not imply that, but that’s only the starting point.

The overall goal of BDD is to move your thinking to the next level, into the land of executable requirement specifications and into the realm of Domain-Driven Design. Automated tests are a good; driving the design is even better for software development, but if you on top of that can get business analysts/subject matter experts, testers and developers to improve the way they capture and understand the ever changing requirements, if they can speak about the requirements and the software using the same vocabulary, and if you can provide them with a way to write acceptance criteria in human readable way that also happens to be executable and that can be mapped directly to the software that will be written - then you have reached what many customers and product owners would call nirvana. The goal of BDD is to help you move you in that direction.

There are tools that are useful for working in a behaviour-driven way, tools that can be of help on your quest to reach this state of development. The first BDD tool that was created was JBehave, but since we are in the Ruby track, we will talk about rspec, which has introduced BDD to a wide audience of test-driven Ruby developers.

If you are interested in this topic and you’re going to JAOO, make sure you come and see us!