Peter Marklund's Home

For me, RailsConf Europe 2007 in Berlin started out with a BDD/RSpec tutorial with David Chelimsky, Dan North, and Aslak Hellesøy. In the first part of the tutorial the presenters gave an overview of the theory and background of Behaviour Driven Development (BDD). All I can offer here is an unstructured list of keywords and notes that I was able to scrabble down while listening:

  Domain Driven Design.
  Having engineers and business people speak the same language.
  SOA
  Using contracts that say: this is all I'm going to do for you
  Focusing on outcomes and reducing features  
  The Agile Alliance
  The false civil engineering analogy of building bridges
  SCRUM  
  Problem: programmers deleting tests they don't understand
  Format for user stories: index cards
  The given-when-then format
  Book: "User Stories Applied"
  All features should be traceable to a persona
  Keeping personas in FaceBook is a fun idea
  Example Driven Development  

After the first break David Chelimsky demonstrated how RSpec is used to do Behaviour Driven Development. Suppose you are having a conversation with your customer about the application that you are going to build. It turns out you need a User class. In RSpec this is expressed as:

describe User do
end

When we run the specification we get a failure since the User class doesn't exist yet. We proceed to add the the User class, re-run the specifications, and get the green light. The green light means we can go back into specification mode and describe the behaviour of our class. The idea with RSpec is to have development of your application proceed in very short cycles including the following steps:

1. Add one or two lines of RSpec specification code
2. Run the specification and get the red light
3. Implement the simplest possible code that will fulfill the specification
4. Run the specification again and get the green light

Suppose your customer says users should be in the role to which they are assigned. In RSpec we express this as:

module Auth
  describe User do
    it "should be in a role to which it is assigned" do
      aslak = User.new
      aslak.should be_in_role("speaker")
    end
  end
end

Throughout the tutorial David Chelimsky used autotest to run the specs continuously in the background. David mentioned that refactoring means improving the design of a system without changing its behaviour. The hard question to answer is whether behaviour has been changed after a refactoring, and it's in the ability to answer that question that BDD/TDD can help us.

Story Runner is a new and complementary specification format that RSpec will provide in the next release. It is structured around scenarios with Given/When/Then blocks and the syntax looks a little something like this:

Story "Plan cup", %{
  Narrative here
}, :type => RailsStory do
  Scenario "set up a 4 team cup structure" do
    Given "a new cup with max teams of", 4 do |max_teams|
    end

    When "I ask to see it" do
    end
    
    Then "it should a row count of", 3 do      
    end
    
    Then "..." do      
    end
  end
end

Stories live in a directory called stories next to the specs directory that RSpec already provides. The specifications deal with the units/components of the system. Stories on the other hand are higher level and are a form of acceptance/integration test that makes sure that the system works as a whole.