removing differences between step types

[MehdiK]

Inspired by Cucumber, I would like to suggest to remove any difference from step types. We currently differentiate between Given, AndGiven, When, AndWhen, Then and AndThen in a few different places. This will help fix #35 and #85.

This is going to be a breaking change as it will touch configuration points and also changes some of expected behaviors (particularly upon exceptions) but I thought while we're in the business of breaking everything we might break this one too ;)

[robdmoore]

Currently if there is an exception in a then it will execute the other thens anyway.

Sometimes this is useful and sometimes it's annoying :p What do you propose would happen to that behaviour as part of this change?

[MehdiK]

When I was creating bddify it somehow felt right to run all thens even if some of them fail. Now I don't care about this much to be honest. If a test is red it's red and should be fixed regardless of whether it's given, when, then or one of the and steps that's failed. Knowing how many and which one of thens fail at one hit could potentially speed up the process; but I think it's not that big a deal. Also this goes against complex flows (#35): if a then fails and there is a given after it, I think we should stop the pipeline. This paradigm also matches cucumber's.

There is currently a configuration, StopExecutionOnFailingThen, that causes the pipeline to stop when there is a failing then. I think we could default to that in V4. Perhaps we could keep the configuration around for those who like the current behavior.

[robdmoore]

Sounds solid to me :)

[JakeGinnivan]

Agree

[JakeGinnivan]

Or maybe only differentiate thens.

That way if I have multiple related Thens I can see just the one which failed, and know that the rest succeed. Just an idea

[MehdiK]

As per my comment on example scenarios, running thens after some have failed could make the report tricky and ugly. Still open to this; but I think the disadvantages outweigh the tiny advantages.

[JakeGinnivan]

Lets go ahead with this, I think we need to include this in v4

[MehdiK]

Yeah, I think this definitely should go into v4 as it's a breaking change.

While this is a prerequisite to #35 it's not the same. So adding a few bits here to make sure it's captured.

After doing this we should add support for more complex behaviors like

Given something
When something happens
Then something is true
When something else happens
Then something else is true
When you try something
Then you see something

where we can chain many given-when-thens together.

This introduces some complexities, particularly for reflective API. For fluent API, it's a matter of adding support for going from Then or And Then to Given or When which can be done by adding to fluent interfaces and implement them. For reflective API this is going to be a bit more difficult though as suddenly the order of steps defined in the class become critical. One way around this would be to use the Order from ExecutableAttribute to dictate the desired order when things go crazy.

[JakeGinnivan]

Would the order the methods are defined in the class not enough? Is that consistent?

[mwhelan]

that's the million dollar question. I'm not sure if you can guarantee the
order with reflection can you?

On Wed, Apr 9, 2014 at 9:32 AM, Jake Ginnivan notifications@github.comwrote:

Would the order the methods are defined in the class not enough? Is that
consistent?

Reply to this email directly or view it on GitHubhttps://github.com//issues/87#issuecomment-39940045
.

[MehdiK]

You can; but it's a bloody magical convention to follow ;)

It gets much worse when you put some of the shared steps in a base class and subclass it in your scenarios. Well, the Order is in there, and people can use the convention if they want until it falls apart at which point they can hardcode it on the steps.

[JakeGinnivan]

http://msdn.microsoft.com/en-us/library/4d848zkb(v=vs.110).aspx - says do not depend on order.

But a cool workaround is:

[AttributeUsage(AttributeTargets.Property, Inherited = false, AllowMultiple = false)]
public sealed class OrderAttribute : Attribute
{
    private readonly int order_;
    public OrderAttribute([CallerLineNumber]int order = 0)
    {
        order_ = order;
    }

    public int Order { get { return order_; } }
}


public class Test
{
    //This sets order_ field to current line number
    [Order]
    public int Property2 { get; set; }

    //This sets order_ field to current line number
    [Order]
    public int Property1 { get; set; }
}

It relies on the compiler injecting the line number, which makes everything ordered properly without forcing the user to explicitly put the order into ExecutableAttribute