On 2015-07-13 09:12, Atila Neves wrote:


Also on HN, but as usual can't post the link.


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

Reply via email to