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?
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|
Define these methods within a namespace (to avoid them being global)
You can then use that module with Cucumber using:
or with RSpec features:
feature "..." do
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.
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.
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.
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.