Ruby on Rails

Cucumber Rails support built-in, and I really recommend using Webrat
in the step definitions. Here is how to get you started.

Install Cucumber, Webrat and RSpec

If you use Git for your Rails app, add the following plugins:

git submodule add git://github.com/aslakhellesoy/cucumber.git vendor/plugins/cucumber
git submodule add git://github.com/brynary/webrat.git vendor/plugins/webrat
git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec
git submodule add git://github.com/dchelimsky/rspec-rails.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.
As a last resort, download tarballs from GitHub.

Install Other dependencies

gem install term-ansicolor treetop diff-lcs hpricot

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

Take a look at the generated files. If you need to, you can go and 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 color description

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.

Run features

rake features

This should result in failing scenarios, because you haven’t written any code yet (I hope). Now you 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

See Running Features for more info.

Tips

These tips apply to Rails development in general…

• Talk to models directly in Given steps to set up a known state. Don’t use fixtures.
• Use Webrat in When steps
• Use response.should have_tag(…) (and models) in Then steps to verify the outcomes (which are on the screen, not only in the database).
• Organise steps in files named accordingly to resources used
• Avoid keeping object state in @variables in steps. It will couple your steps and make them harder to reuse.

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 view specs. I recommend you delete generated view specs if you run into too much maintenance
headaches and rely on the features instead of view specs. However, in some cases it can be handy to use both.