Skip to content


Subversion checkout URL

You can clone with
Download ZIP

Ruby on Rails

aslakhellesoy edited this page · 82 revisions

Cucumber supports Ruby on Rails out of the box. Currently the following Rails versions are tested with cucumber-rails-test

  • v2.3.4
  • v2.3.3
  • v2.3.2
  • v2.2.2
  • v2.2.1
  • v2.2.0
  • v2.1.2
  • v2.1.1
  • v2.1.0

Older versions will never be supported as it requires too much work.

We strongly recommend you use Webrat in the Step Definitions. Here is how to get you started.

Install Cucumber, Webrat and RSpec

Ubuntu/Debian users: Follow these Nokogiri install instructions first.

You can use both Rubygems or Rails’ plugin mechanism. We usually recommend Rubygems. You can read a longer discussion here.

Using Rubygems

The easiest is to install everything as a gem.

[sudo] gem install rspec rspec-rails cucumber webrat

If you use gems, you have to make sure everybody on the team has the same version of the gems installed. Also note that you don’t have to use rspec and rspec-rails and webrat, but we suggest you use them unless you have good reasons to use something else.

Using plugins

Another option is to install the libraries as Rails plugins. If you use Git for your Rails app, here is how to do that:

git submodule add git:// vendor/plugins/cucumber
git submodule add git:// vendor/plugins/webrat
git submodule add git:// vendor/plugins/rspec
git submodule add git:// vendor/plugins/rspec-rails

If your own Rails code is not in Git, just replace submodule add with clone.
If you’re behind a proxy, try to replace git:// with http:// and set the http_proxy environment variable.

Install dependencies

The plugins’ dependencies must be installed separately:

gem install term-ansicolor treetop diff-lcs nokogiri builder

Behind a firewall?

As a last resort, download tarballs from GitHub.

Create Your Rails Project

Create the rails project with the following command:

rails YourProjectName

Don’t forget to create the corresponding databases.

Write all commands in the next steps from this project’s path.

Bootstrap Cucumber

You’ll need a Rake task and a couple of files that configure Cucumber for use with Ruby on Rails and Webrat.
You create these with:

ruby script/generate cucumber

We recommend you use Spork and --drb so you can run your features faster:

ruby script/generate cucumber --spork

For more help on the generator you can just ask for help:

ruby script/generate cucumber --help

Take a look at the generated files. If you need to, you can tweak them later.

Start a feature

It’s really, really recommended that you write your features by hand – in collaboration with your
customer / business analyst / domain expert / interaction designer. However, to get you started (and so you can see how to use Webrat), you can use the feature generator to generate the first few features:

ruby script/generate feature Frooble name:string color:string description:text

This will generate a simple plain text feature with associated steps. Don’t get addicted to this
generator – you’re better off writing these by hand in the long run.

Important: The generated feature will fail unless you have set up a layout in your app. This is because Webrat fails to parse HTML
that isn’t well formed (i.e. has a single <html> root node). Here is a simple layout you can use, but I hope you have a better one yourself.

Run features

If working on a fresh Rails project, first set up the (empty) database:

rake db:migrate

(Otherwise Cucumber fails with the error no such file to load -- YourProjectName/db/schema.rb.)

Then run the features:

rake features

This should result in failing scenarios, because you haven’t written any code yet (I hope).

Now it’s time to write some code, or generate some. Try this:

script/generate rspec_scaffold Frooble name:string color:string description:text
rake db:migrate
rake features

Other ways of running features

You can also run specific features directly with cucumber:

cucumber --require features --require lib features/subdir/
cucumber --require features --require lib features/some-nifty.feature

And using autospec with a similar setting (--require features --require lib), applied in your project’s /cucumber.yml:

autotest-all: --require features --require lib --format progress features
autotest: --require features --require lib features  
default: --format pretty
html: --format html --out features.html

Remember that you need AUTOFEATURE=true for autospec to include cucumber features. See Running Features and Autotest Integration for more info.

Special tags

There are two special tags you can use to change how Cucumber runs your scenarios


By default all scnearios will run within a database transaction that is rolled back at the end. However, scenarios tagged with @no-txn will run without a transaction. This can be useful when you have to deal with Browsers and Transactions. Beware that this will leave data in your database after that scenario, which can lead to hard-to-debug failures in subsequent scenarios. If you use this, we recommend you create a Before block that will explicitly put your database in a known state, for example using DatabaseCleaner


Scenarios tagged with @allow-rescue will cause Rails to rescue all errors and render error pages, more or less in the same way your application would behave in the default production environment. It’s not recommended to do this for all of your scenarios, as this makes it hard to discover errors in your application.

Controller and View spec redundancy

Since I recommend you verify outcomes (Then steps) by looking at the HTML, you might end up having some degree of redundancy with controller and view specs. I recommend you delete generated controller and view specs if you run into too much maintenance headaches and rely on the features instead. However, in some cases it can be handy to use them.


Some guidance for authentication is provided below. It is recommended that a new user is created, rather than loaded through fixtures or etc.

In the .feature, use a phrase similar to Given a user is logged in as "markEmark", and add the following to your relevent step definitions.

Given /^a user is logged in as "(.*)"$/ do |login|
  @current_user = User.create!(
    :login => login,
    :password => 'generic',
    :password_confirmation => 'generic',
    :email => "#{login}"

  # :create syntax for restful_authentication w/ aasm. Tweak as needed.
  # @current_user.activate! 

  visit "/login" 
  fill_in("login", :with => login) 
  fill_in("password", :with => 'generic') 
  click_button("Log in")
  response.body.should =~ /Logged/m  
Something went wrong with that request. Please try again.