Spread the word!

https://www.youtube.com/watch?v=bxSPCmwqgYs
https://www.youtube.com/watch?v=jNQF3m5e2l0

Andrei

On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote:
> Spread the word!
>
> https://www.youtube.com/watch?v=bxSPCmwqgYs
> https://www.youtube.com/watch?v=jNQF3m5e2l0
>
> Andrei

Erich's presentation is now my favourite one from this year's DConf. If you read this Erich, I really love your energy! Such nice display is, to me, as important as more technical presentations of D as they touch different people. Thank you!

On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote:
> Spread the word!
>
> https://www.youtube.com/watch?v=bxSPCmwqgYs
> https://www.youtube.com/watch?v=jNQF3m5e2l0
>
> Andrei

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

On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote:
> Spread the word!

https://www.reddit.com/r/programming/comments/3d66zk/why_i_love_d_an_undergrad_shares_his_experience/

On Monday, 13 July 2015 at 07:12:48 UTC, Atila Neves wrote:
> On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote:
>> Spread the word!
>>
>> https://www.youtube.com/watch?v=bxSPCmwqgYs
>> https://www.youtube.com/watch?v=jNQF3m5e2l0
>>
>> Andrei
>
> 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

Very cool techniques you've done there. I think you may have convinced me that Cucumber might be worth trying out. It does seem like you have to spend a lot of effort doing the plumbing to get it working (all the regexes) so I'm not completely sold but you've made it sound compelling enough to give it a whirl.

On Tuesday, 14 July 2015 at 20:18:40 UTC, Brad Anderson wrote:
> On Monday, 13 July 2015 at 07:12:48 UTC, Atila Neves wrote:
>> On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote:
>>> Spread the word!
>>>
>>> https://www.youtube.com/watch?v=bxSPCmwqgYs
>>> https://www.youtube.com/watch?v=jNQF3m5e2l0
>>>
>>> Andrei
>>
>> 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
>
> Very cool techniques you've done there. I think you may have convinced me that Cucumber might be worth trying out. It does seem like you have to spend a lot of effort doing the plumbing to get it working (all the regexes) so I'm not completely sold but you've made it sound compelling enough to give it a whirl.

Cucumber even gives you the regexes after you write the feature. All you have to do is write the code that should be run, really.

Atila

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

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.

The comment about not having to name the steps. One way to do that could be something like this:

step("foo bar", {
    // step implementation
});

There are two problems with that:

1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call.

2. That syntax is not as nice as in Ruby. It would be really nice if the following could be supported:

step("foo bar") {
    // step implementation
}

A trailing delegate syntax, where the delegate is passed after the regular argument list.

-- 
/Jacob Carlborg

On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg wrote:
> 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.
>
> The comment about not having to name the steps. One way to do that could be something like this:
>
> step("foo bar", {
>     // step implementation
> });
>
> There are two problems with that:
>
> 1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call.

Do mixin templates work on module level? They can even have an identifier.

>
> 2. That syntax is not as nice as in Ruby. It would be really nice if the following could be supported:
>
> step("foo bar") {
>     // step implementation
> }
>
> A trailing delegate syntax, where the delegate is passed after the regular argument list.

Unfortunately there are syntactical ambiguities:

    step("foo bar") {
    }
    .foo();

Is that a call chain, or two statements, with the second one calling a function in the root scope? And I think there are other similar cases...

On 2015-07-16 10:26, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:

> Do mixin templates work on module level? They can even have an identifier.

Yes. But a mixin template seems only be able to contain declarations. How did you plan to use it?

> Unfortunately there are syntactical ambiguities:
>
>      step("foo bar") {
>      }
>      .foo();
>
> Is that a call chain, or two statements, with the second one calling a
> function in the root scope? And I think there are other similar cases...

Hmm, right. I have simple implementation of this. With you're example I get this error message:

function main.foo () is not callable using argument types (void function() @safe)

-- 
/Jacob Carlborg