On 2015-04-02 23:46, Wyatt wrote:
Dealing with it at work, I find it puts us scarily at the mercy of
regexen in Ruby, which is unsettling to say the least. More pressingly,
the "plain English" method of writing tests hinders my ability to figure
out what the test is actually trying to do. There's not enough structure
to give you good visual anchors that are easy to follow, so I end up
having to build a mental model of an entire feature file every time I
look at it. It's hugely inconvenient. And if I can't remember what a
phrase corresponds to, I have to hunt down the implementation and read
that anyway, so it's not saving any time or making life any easier.
At work we're using Turnip [1], which basically is Gherkin (Cucumber)
files running on top of RSpec, best of both worlds Dicebot ;). It has
two big advatnages compared to regular Cucumber:
* It doesn't use regular expression for the steps, just plain strings
* The steps are implemented in modules which are later included where
needed. They're not floating around in global space like in Cucumber
We also made some modifications so we have one file with one module
matching one scenario, which is automatically included based on the
scenario name. This made it possible to have steps that don't interfere
with each other. We can have two steps which are identical in two
different scenarios with two different implementations that doesn't
conflict.
This also made it possible to take full advantage of RSpec, by creating
instance variables that keeps the data across steps.
We're also currently experimenting with a gem (I can't recall its name
right now) which allows to write the Cucumber steps inline in the RSpec
tests, looking like this:
describe "foobar" do
Steps "this is a scenario" do
Given "some kind of setup" do
end
When "when something cool happens" do
end
Then "something even cooler will happen" do
end
end
end
[1] https://github.com/jnicklas/turnip
--
/Jacob Carlborg
