Last - but not least! - two DConf talks

[Jacob Carlborg via Digitalmars-d-announce]

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