-
Notifications
You must be signed in to change notification settings - Fork 0
Ruby on Rails
Cucumber-Rails lets you use Cucumber with Ruby on Rails.
Go to Cucumber-Rails’ README for installation instructions and ignore this page.
As of Cucumber-Rails version 0.5.0 and above, Cucumber-Rails only supports Rails 3.x (Rails 2 is not supported). The following is only for Rails 2.×.
If you are on Rails 2.x you have to use an older version of Cucumber-Rails. These are the recommended versions for maximum compatibility with Rails 2.3.x:
gem "capybara", "1.1.1"
gem "cucumber", "1.1.0"
gem "cucumber-rails", "0.3.2"
The rest of this page describes how to install Cucumber-Rails in a Rails 2.x application. These instructions assume you already have a Rails 2.x application, and that you have a shell where the current directory is the root of your Rails app.
[sudo] gem install cucumber-rails -v 0.3.2The cucumber-rails gem depends on the cucumber gem, so you don’t need to install that separately.
Cucumber-Rails needs to add a few files to your project:
ruby script/generate cucumberIf 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 --sporkFor more help on the generator you can just ask for help:
ruby script/generate cucumber --helpTake a look at the generated files. If you need to, you can tweak them later.
[sudo] rake RAILS_ENV=cucumber gems:installIt’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 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.
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
You can also run specific features directly with cucumber:
cucumber --require features --require lib features/subdir/
cucumber --require features --require lib features/some-nifty.featureAnd 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.htmlRemember 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.htmlThere are two special tags you can use to change how Cucumber runs your scenarios
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
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.
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}@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