Execute each step immediately after it is defined

[adamralph]

Spun off from #361 raised by @epitka

The wiki page for reusing steps previously described an alternative method of the form:

"Given..."
    .x(() => ...);
"When..."
    .x() => ...);
Then.CoolOutcomes(result);

This does not work in 2.x, since the steps are defined while the scenario method is running, and executed afterwards. IIRC this did work in 1.x since each step was executed immediately after being defined, but this changed to deferred execution in 2.0.

I think this is a breaking change so will require a version bump to 3.0, but I'll have to consider that a little more before being sure.

[enzian]

What was the original incentive for moving to deferred execution? (I think I'd be able to do without it!)

[adamralph]

@enzian IIRC I didn't make a conscious decision to change to deferred execution.

xbehave 2.0 was a complete rewrite from scratch (due to the complete rewrite from scratch of xunit 2.0). The xbehave 2.0 acceptance tests were carried over from 1.x and immediate execution was not an enforced invariant in 1.x.

Perhaps immediate execution was something that resulted naturally from the xunit 1.x extensibility model and deferred execution from the xunit 2.0 model. I'm not entirely sure whether immediate execution is even possible with xunit 2.0.

[ursenzler]

If possible, I'd prefer immediate execution because we had to introduce some dummy steps in our tests to compensate for deferred execution. Also, it's something that people I teach about xBehave struggle with, in the beginning.

[adamralph]

@ursenzler that's interesting. Could you provide an example please?

[ursenzler]

@adamralph I'll have to show you in our code, I struggle to explain it without context.

[adamralph]

@ursenzler I can only imagine that you must have a need to execute specific code outside step delegates. If everything is inside, then everything is deferred and you should not have any problems.

The basic premise of xbehave is that everything should be inside step delegates. If something is outside, then yes, I can imagine that the deferred execution could be problematic. If indeed you do have a need to execute code outside steps, I'd very much like to know more about it, so that we can investigate what needs to be done to avoid having to do that.

Incidentally, I've had it on my to-do list for some time to include an analyzer in xbehave that warns when a scenario contains anything outside a step delegate.