Skip to content
This repository

IMPORTANT: See Cucumber-Rails’ README for updated instructions for Rails3. This page will be updated with Rails3 info later.

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

  • v3.0.0.beta
  • v2.3.5
  • 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. These instructions assume you already have a Rails project, and that you have a shell where the current directory is the root of your Rails app.

Install Cucumber-Rails

[sudo] gem install cucumber-rails

The cucumber-rails gem depends on the cucumber gem, so you don’t need to install that separately.

Bootstrap Cucumber-Rails

Cucumber-Rails needs to add a few files to your project:


ruby script/generate cucumber # Rails 2
rails generate cucumber:install # Rails 3

If you’re on an OS that supports fork we recommend you use Spork and --drb as this lets you start cucumber 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.

Install new dependencies

[sudo] rake RAILS_ENV=cucumber gems:install

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 you can use the feature generator to generate the first few features:

ruby script/generate cucumber: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 cucumber

(You may run rake -T cucumber to see the other rake tasks available)

This should result in a statu quo, 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 cucumber

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.

For autospec, change autotest in the above block to autospec:

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

Special tags

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

@no-txn

By default all scenarios 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

@allow-rescue

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.

Authentication

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}@example.com"
  )

  # :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  
end

Rails plugins

  • Courgette Rails engine (plugin) for Rails 2.x applications which makes your cucumber features files viewable through your browser
  • Cucumber Feature Manager Help to manage with big amount of features in project, demo
Something went wrong with that request. Please try again.