Yeah, But Is It Flash?

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.

If you guys will allow me I think I’ll talk about something other than Flash today. No I’ve not lost my marbles but there are a few other sessions from last weeks Developer! Developer! Developer! event that I’d like to talk about.

Both Liam Westley and Steve Sanderson presented sessions that were real eye openers for many attendees. What I found most interesting was that a lot of what they had to say was simply common sense. Unfortunately geeks tend not to apply common sense instead burying themselves in code or sticking to procedures that they’ve grown comfortable with.

Liam’s “Writing Software is Easy, Not Going Bust is the Hard Part” was a breath of fresh air with technology and frameworks being completely avoided. Instead the focus was on testing, logging, time/cost estimates, paperwork and sales pitches. I guarantee all attendees at one point or another during the hour felt slightly embarrassed when they realised that they (or their company) weren’t actually following many of simple practices outlined by Liam.

Things didn’t start too well for us. “Your goal as a software company is to create software that never causes that support phone to ring”. “Every time the phone rings you bleed cash”. MacDog was sweating by this point as he desperately fumbled about in his pocket trying to switch our support phone onto silent mode. Phew disaster averted. The talk then moved onto error reporting and logging, where again there were some great points for us to follow-up on.

Later on we covered the more mundane but no less important, with Liam going as far as suggesting you should eject people from meetings who haven’t bothered reading the documentation beforehand. Again, it’s common sense really as it leaves only those who are actually prepared and ultimately leads to a more productive meeting.

For me, his best tip was to always try and be the guy that gets to write the minutes. Why? Simple, no one bothers to read them and what is written in them tends to get set in stone. As Liam said, “Victory goes to those who write the minutes”.

As a company I think the processes and procedures we have in place at WeeWorld are extremely good, but it’s clear that there is still room for improvement. There are a few great things we took away from the session that we plan to discuss and take further. But what I found most interesting from the session was that much of what was said focused on just the small day-to-day tasks that everyone and every company has no reason for avoiding. It’s really all about discipline and a dash of common sense.

I strongly suggest you watch the video above of Liam’s presentation and take the time to read over his presentation slides complete with speaker notes.

I’m gonna talk a little about Steve Sanderson’s brilliant “Behaviour Driven Development” next time and then I promise I’ll get back to feverishly talking about Flash.