Before we can begin doing BDD (behavior driven development) we need to install some tools to help.

sudo gem install cucumber rspec-rails webrat

Next I go to my Rails application and run some scripts to get the basic set-up inside my rails directory structure:

script/generate rspec
script/generate cucumber

Now in the newly created features folder I will create a file called user_administration.feature. This file will contain all my scenarios for this feature. After spending some time thinking about how to express my features I come up with two basic ones to start:

Feature:  User Administration

So that I can control access to the application
As an admin
I want to manage users

Scenario: Create a new user account
  Given no user "joetest"
  When I create a new user "joetest" with password "skymonkey"
  Then the user "joetest" can log in with password "skymonkey"

Scenario: Suspend an existing user account
  Given a user that is active
  When I suspend the user
  Then the user can not log in

Now I run the following command to have cucumber generate snippet methods that I can then copy into a step definition.

script/cucumber features/user_administration.feature

I create a new file named user_steps.rb in the features/step_definitions folder. Now that we have our step definition snippets the next job is to take them from “pending” into something meaningful. We’ll start with the first scenario. After giving it some thought it might end up looking like this:

Given /^no user (.+)$/ do |login|
  lambda{ User.find(login) }.should raise_error(ActiveRecord::RecordNotFound)
end

This first part sets us up. It allows us to express the given state, in this case not finding a user named “joetest”.

When /^I create a new user "(.+)" with password "(.+)"$/ do |login, password|
  visit new_user_path
  fill_in "user_login", :with => login
  fill_in "user_email", :with => "#{login}@test.org"
  fill_in "user_password", :with => password
  fill_in "user_password_confirmation", :with => password
  click_button "Sign Up"
end

Next we describe the action we’ll be taking. This code simulate the submission of a form, using Webrat. We take this approach because it makes us exercise the whole stack views, controller and models. It’s just short of me going to the site with a browser.

Then /^the user "(.+)" can log in with password "(.+)"$/ do |login, password|
  visit login_path
  fill_in "login", :with => login
  fill_in "password", :with => password
  click_button "Log In"
  response.should contain("Logged in Successfully")
end

Lastly we test our outcome, that the user the admin created is able to log in. So the end result is test that describes the behavior of an admin creating a new account for a user, and they are able to successfully log in.

Along the way you may find tests go red (fail), this is normal. You want to write code (just enough) to make them go green, then continue to write more test code. Keep repeating this until all your tests run green.

Also the nice thing about step definitions is that they can be reused in other tests. We’ll likely have other scenarios where we create a new user or try to log in as one. Our code stays dry and we (the developer) stay confident. (Now it’s sounding like a anti-perspirant commercial, so I’ll stop now.)

Traditionally when you do emergent design, at least in my experience, you go from the inside out. Work from your model into your controller and views. Since web applications are so heavily focused on user interaction it sometimes is better to work from the outside in. When working with a Rails application think instead of your views and work into your controller and models.

Understand the UI first before you write any code. Use things like paper prototyping to understand real user data needs and challenges. Paper prototyping is a cheap and easy way to understand what objects and data a user will be interacting with for a given task. Keep your session short, and focus only on the feature you’re developing. You can find examples of paper prototyping on YouTube.

Get boot-strapped with Cucumber, RSpec and RSpec-Rails, and dive straight into BDD on your Rails project. To do this you need to install various gems to support your development efforts:

sudo gem install cucumber rspec-rails webrat
cd my_rails_project
script/generate cucumber
script/generate rspec

That’s all you have to do to get going! You’ll notice that you’ll have a new features folder and the usual spec folder (from RSpec). You will want to describe your features as stories and scenarios for Cucumber in the features folder. Start with your views when you think about scenarios.

The basic gist of it is just like regular TDD, except we are focusing on behavior:

1. Choose a single Cucumber scenario
2. Create a failing step definition in Cucumber
3. Create a failing spec in RSpec
4. Write code to make the spec pass (red/green refactor)
5. Repeat 3 and 4 until the scenario is passing

In the process of making the scenario pass you’ll find yourself discovering models and controllers that will need to be written or updated. Taking this type of approach helps you focus on writing just enough code to get your tests passing, without over engineering, and has the added benefit of you writing testable code. (Remember TDD/BDD is not so much about testing as it is about communication, documentation and design!)

Your finished scenario should touch a complete vertical slice of your application, that is to say, model->controller->view. It should provide some real value to the user. Agile development philosophies frown on partial feature delivery. A schema, security filter or screen alone is not a feature. If you write scenarios from the user’s perspective you’ll avoid this pitfall.

To learn more about Cucumber and RSpec (either in Rails, or plain Ruby) I would recommend checking out Pragmatic Bookshelf, they have a beta book on RSpec.