Order of multiple tag hooks

[Jonathan Greenberg]

I am finding that when I have multiple tag hooks on a scenario they
appear to be run in the order that they are defined in the hooks
file(s) and not according to the order that the hooks are being listed
in the scenario.

Is this expected behavior or this a bug? It would be much more
convenient for it to be follow the order of the tags.

[aslak hellesoy]

On Tue, Aug 9, 2011 at 5:23 PM, Jonathan Greenberg
<gree...@entryway.net> wrote:
> I am finding that when I have multiple tag hooks on a scenario they
> appear to be run in the order that they are defined in the hooks
> file(s) and not according to the order that the hooks are being listed
> in the scenario.
>
> Is this expected behavior or this a bug?

It's by design

> It would be much more
> convenient for it to be follow the order of the tags.
>

Not necessarily. Sometimes hooks depend on each other, in which case
changing their execution order would break that dependency.

Why do you need to control the order from gherkin?

Aslak

> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>
>

[Jonathan Greenberg]

>
> Why do you need to control the order from gherkin?
>

We are experimenting with a new pattern where we use tagged hooks to
set up certain objects needed in many of our features. Sometimes there
are dependencies so the order in which they are run is important and
it makes the most sense for this to be defined by the scenario. Here
is a rough example:

@logged_in_member @active_product
Scenario

Before '@logged_in_member'
@account = Factory(:account)
@member = Factory(:member, :account => @account)
log_in_member_to_account(@account)
end

Before '@active_product'
Product = Factory(:product, :account => @account)
end

It appears that if the '@active_product' hook is defined first then
the feature blows up because '@logged_in_member' is called second
since @account is nil.

We are also starting to group our hooks in separate files and the
order that these get loaded becomes alphabetical to file name.

I hope this all makes sense. I was expecting how the tags get listed
in the scenario to determine the order the tags get run.

Also, on a related note, when an error happens in a hook we get a
scenario failure but without any helpful output as to what went wrong.
Is there a way to change that?

Thanks for the prompt response!

Jonathan.

[aslak hellesoy]

On Tue, Aug 9, 2011 at 6:13 PM, Jonathan Greenberg
<gree...@entryway.net> wrote:
>
>>
>> Why do you need to control the order from gherkin?
>>
>
> We are experimenting with a new pattern where we use tagged hooks to
> set up certain objects needed in many of our features. Sometimes there
> are dependencies so the order in which they are run is important and
> it makes the most sense for this to be defined by the scenario. Here
> is a rough example:
>
> @logged_in_member @active_product
> Scenario
>
> Before '@logged_in_member'
>  @account = Factory(:account)
>  @member = Factory(:member, :account => @account)
>  log_in_member_to_account(@account)
> end
>
> Before '@active_product'
>  Product = Factory(:product, :account => @account)
> end
>
> It appears that if the '@active_product' hook is defined first then
> the feature blows up because '@logged_in_member' is called second
> since @account is nil.
>
> We are also starting to group our hooks in separate files and the
> order that these get loaded becomes alphabetical to file name.
>
> I hope this all makes sense.

I understand what you are doing, but it doesn't make much sense to me :-)

Your "pattern" is essentially replacing the core concept steps+step
definitions with tags+hooks. This is stretching tags too far, and I
don't understand what you hope to achieve by that. Have you tried the
more conventional style:

Scenario:
Given a logged in user
And an active product

Given /a logged in user/ do

@account = Factory(:account)
@member = Factory(:member, :account => @account)
log_in_member_to_account(@account)
end

Given /an active product/

Product = Factory(:product, :account => @account)
end

This is how everybody else uses Cucumber. Bonus points: Your features
are readable, and you're in control of the execution order.

> I was expecting how the tags get listed
> in the scenario to determine the order the tags get run.
>

The docs are clear that this is not the case:
https://github.com/cucumber/cucumber/wiki/Hooks

> Also, on a related note, when an error happens in a hook we get a
> scenario failure but without any helpful output as to what went wrong.
> Is there a way to change that?
>

I believe that's an old bug. It should be in the tracker somewhere -
maybe you'll find some details there. Patches are welcome.

Aslak

> Thanks for the prompt response!
>
> Jonathan.
>

[Matt Wynne]

I agree with Aslak, but if you do want to carry on and try to make this pattern work, I'd suggest putting your instance variables behind memoizing getter methods, so that the dependencies are more robust, and the order the hooks run doesn't matter:

module MyWorld
def account
@account ||= Factory(:account)
end

def member
@member ||= Factory(:member, :account => account)
end
end

Before '@logged_in_member' do
member
log_in_member_to_account(account)
end

>
>> I was expecting how the tags get listed
>> in the scenario to determine the order the tags get run.
>>
>
> The docs are clear that this is not the case:
> https://github.com/cucumber/cucumber/wiki/Hooks
>
>> Also, on a related note, when an error happens in a hook we get a
>> scenario failure but without any helpful output as to what went wrong.
>> Is there a way to change that?
>>
>
> I believe that's an old bug. It should be in the tracker somewhere -
> maybe you'll find some details there. Patches are welcome.
>
> Aslak
>
>> Thanks for the prompt response!
>>
>> Jonathan.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Cukes" group.
>> To post to this group, send email to cu...@googlegroups.com.
>> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Cukes" group.
> To post to this group, send email to cu...@googlegroups.com.
> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>

cheers,
Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book (with Aslak Hellesøy)
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne