← Back to Upcase

Migrating Cucumber features to RSpec feature specs


(Aaron Mc Adam) #1

Hi guys

Increasingly our cukes aren’t providing much value. Nobody outside our team reads them and the way we have to implement the steps for our system to work properly has gotten out of control.

I was wondering if anyone had any tips or advice on moving from Cucumber to RSpec feature specs for acceptance testing. I’d like to try moving over one feature at a time as each feature gets changed, rather than just moving everything for the sake of it.

Just wondering if anyone had any tales of woe regarding moving? How did the thoughtbotters find the move?


(Andy Waite) #2

I’ve used both Cucumber and RSpec features, but never actually had to migrate things across. But if I was to do this, here’s how I would approach it:

Define/refactor your Cucumber steps so that they do not actually have any behaviour, but simply delegate to a plain Ruby method (so probably just a single line per step). For example:

Given /^a widget named "(.*)"$/ do |name|
  create_widget_named(name)
end

Define these methods within a namespace (to avoid them being global)

module Steps
  module Widgets
    def create_widget_named(name)
      Widget.create!(name: name)
    end
  end
end

You can then use that module with Cucumber using:

World(Steps::Widgets)

or with RSpec features:

feature "..." do
  include Steps::Widgets
end

So now when you add a new RSpec feature, you’ll be able to make use of the the existing step definitions you already have.


(Andy Waite) #3

I should also say, RSpec features are not the silver bullet to better integration specs. You can still end up with all the same problems of slow and brittle tests. My approach these days is aim for just one happy path and one failure path integration test through each major feature, and to test everything else at the unit level.


(Aaron Mc Adam) #4

I’ve already got that in place, with a method for every single step def. Now I’ve started just inlining the definitions in some places as I was following the rule a bit too closely. It can make it hard to follow what a test is testing too with so much indirection to helpers. The Mystery Guest anti-pattern can be a major problem when extracting test helpers too.


(Aaron Mc Adam) #5

Yeah I would say that I need to re-evaluate our acceptance/integration test style but I think we need to move away from gherkin for a while in order to try a fresh approach.