Behaviour Driven Development

My favourite presentation at this years DDD Scotland was Steve Sanderon’s “Getting Started with Behaviour-Driven Development (BDD)”. No don’t close your browser! This is gonna be a good post, honest.

So what the heck’s Behaviour-Driven Development then? Well funnily enough Steve doesn’t pretend to be an expert on the subject, going as far as stating that he’s not sure you’ll find an accurate description of BBD anywhere.

No no no don’t go! I’m not kiddin’ you’ll get something out of this one, just hang on in there, because to be honest I think our presenter here was being a tad modest. He seemed to really know what he was talking about and I’m going to try and summarise below (in other words rip content directly from Steve’s blog). Here goes.

BBD is really a refinement of Test Driven Development (TDD). As Steve pointed out, TDD has an unfortunate name since it is more useful as a code design aid rather than as a technique for testing code and finding bugs. Perhaps it’s biggest problem is that too many developers struggle to break free from a test-oriented mindset, investing time writing and maintaining masses of unit tests that execute every code path without really aiding design or detecting bugs.

Behaviour Driven Development however puts the emphasis on specifying behaviours that can be understood by non-programmers. It extends TTD by writing test cases in a natural language that anyone can read. BBD asks you to elevate your mind to a level of behavioural abstraction above the code implementation. This change leads to the writing of more beneficial specifications.

Although you can write BBD-style specifications for individual code units, it seems that it’s particularly useful when writing specifications for UI interactions. Your specification should make it clear in high-level terms what the application should do and is typically written in a natural language such as Gherkin. Behaviours consist of simple sentence fragments that are written in terms of “Given, When, Then”. Here’s a sample specification written in Gherkin.

Feature: Signing In
     In order to participate on WeeWorld
     As a user
     I must first sign-in to the site

Scenario: Sign-in
     Given I am on the WeeWorld home page
     Then I should see a button labelled "Sign in"
          And a field labelled "Username:"
          And a field labelled "Password:"
     When I enter "test" into the "Username: " field
          And I enter "password1" into the "Password: " field
          And click the button labelled "Sign in"
     Then I am redirected to the home page for the user named "test"

Scenario: Viewing user's home page
     Given I am on the home page for user "test"
     Then I should see a text field labelled "Hi test!"
          And I should see a link labelled "Sign out"

Pretty neat eh? Well that’s the easy part. The final step is to actually write some code to test our business rules. There are tools available (SpecFlow for Dot Net developers and Cucumber for those using Ruby) that take your Gherkin specification and generate a test fixture containing a test method for each of your scenarios. It’s then the task of the developer to start writing test code to verify each of the scenarios. This code will usually take advantage of automation tools such as WaitN or Selenium for integrating your tests with web browsers.

And that’s more-or-less Behaviour Driven Development. Of course if you want to know more I suggest you pop over to Steve Sanderson’s blog where he does a much better job of explaining all this, and gives some examples of code that is written from each of the scenarios. To be honest I couldn’t be bothered going that far 🙂

Okay, you can remove the match sticks from your eyes now.

Oh and if you’re a Flash dude then you might want to take a peek at ASSpec which is a free and open-source behaviour-driven development framework for ActionScript 3. Although to be honest I haven’t really spent any time looking at it myself so it could very well be rubbish.