Behavior Driven Development in a nutshell

A good development practice is to use automated tests to ensure the application works well and to facilitate refactoring. It is even better to write these unit tests before writing the code: this practice is called Test Driven Development (TDD) and it is a great way to check that the code is what it is excepted to be. Behavior Driven Development (BDD) goes a step further as you write specifications describing what the code does.

Behavior Driven Development is more about interactions with the application than just unit testing. It forces the developer to understand the responsibility of the method he is about to write. Using good tools, the specs written to test the application can be used as specifications.

Ruby BDD frameworks

RSpec is famous ruby BDD framework that plays with contexts and assertions. It is mainly used to describe the behavior of application code in specific contexts.

describe Calculator do
  context "switched on" do
    before(:all) do
      @calc = Calculator.new.switch_on!
    end

    it "should have a result equal to 0" do
      @calc.result.should equal(0)
    end
  end
end

These specifications are a good documentation for developers as they focus on the application code. Since BDD encourages collaboration between developers & non-technical participants, we need a tool describing the application at a higher level: Cucumber, to the rescue!

Cucumber permits to describe how the application should behave via user stories written down in a business-readable language. A scenario looks like that:

Given I am on the messages page
When I fill in new_message with "Hello"
  And I press "Send"
Then I should see "Message sent!"

These plain-text scenarios can be shared between developers and non-technical participants to validate the application behavior. Each step of this scenario is defined in Ruby to permits to run the scenario against the application and to generate a detailed development-status report.

BDD process

The focus of BDD is the language and interactions used in the process of software development. It implies outside-in development starting with User Interface definition to code development. Therefor, you create scenarios for the features you would like to develop and then follow the BDD process:

1. for each scenario describing a feature
2. run the scenario – it fails (go red)
3. define the first step – go red
4. write down the application code getting the step to pass – go green
5. refactor the code and repeat steps 4 & 5 for each step until…
6. the scenario passes – go green
7. refactor the application code

Once your done, you can move on to the next feature. :)

These scenarios drive the developer into the development process. It forces him to focus on writing down the test or application code to get the current step to pass, before moving on to the next step. The developer is also gratified every time a step passes and he knows with precision which features work.

I use Behavior Driven Development to develop Ruby on Rails applications. I work with non-technical participants on Cucumber scenario and I can give easily generate a project development status that shows working / pending / not-working scenarios. When switching to “development mode”, I just focus on getting the next step to pass – my mind is free of thoughts concerning the feature definition & application requirements. I usually get a step to pass in a couple of minute and everytime it occurs, it am gratified of seeing it going green. Finally, the refactor process occuring everytime a step or a scenario pass, the application design is constantly evolving to fit just the requirements: that is emergent design.

Many developers I talked with say that it is hard to write tests before writing the code. I think it is just hard to switch to this method. Try it and the coding process will look easier and your code will get better – just because you will specify before coding instead of doing both at the same time.