On 2015-07-13 09:12, Atila Neves wrote:
https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/
Also on HN, but as usual can't post the link.
Atila
Really great talk.
We're using Cucumber (or rather a similar tool called Turnip) a lot at
work and I was using the standard version at my previous work. A couple
of things I don't like with the standard Cucumber are:
1. Regular expressions used for defining steps. Using actual regular
expression is seldom needed, most of the time only a string is needed.
Turnip uses strings with variable support, that is, any word prefix with
a colon will be assumed to be a variable and passed to the block as an
argument.
What can easily happen with regular expression is the steps become too
generic and try to do too much. This can of course happen with strings
as well but it's less likely because a string is more limited on what it
can match.
2. All steps are global. If nothing has changed recently all steps are
available for all features/scenarios. This becomes a problem when you
have similar steps but with different implementation, or rather the data
is different. Which easily happens when you have a lot of features files.
What happened to us was that to be able to share data between the steps
a global associative array was used. This also caused a lot more data to
be present in the feature file than we would have liked. Like
identifiers to find the data in the associative array. Everything had
dependencies on everything else can became a big mess.
We have solved this with a heavily modified version of Turnip. Turnip
uses the Gherkin feature files but is using RSpec as the test runner. We
have modified Turnip so each feature is mapped to a module/namespace,
each scenario is mapped a nested module, which is then included in the
anonymous class that RSpec creates. Each step is mapped to a method in
that anonymous class.
Now we were able to do two things, have steps that are local to a
scenario, without causing any conflicts and share data between the steps
using instance variables. This resulted a completely different thinking
in how to write feature files and how to implement them. We were also
able to remove a lot of unnecessary data from the feature files.
--
/Jacob Carlborg