Run features in a specific order
4,715 views
Skip to first unread message
Dan Claudiu Pop
Feb 28, 2011, 12:55:51 PM2/28/11
to Cukes
Hello,
How can i set cucumber to run features in a specific order ?
I'm using cucumber and watir-webdriver for automated acceptance tests
and i have 3 servers on which the tests run (dev, qa etc). The tests
are cyclic meaning, for, e.g a user is created, posts some stuffs do
some actions and at the end the user is deleted with all his test data
and i can't really use default data on all the servers. I know that
this is not a good approach, features to be dependent on each other
but i'll stick for the moment with this.
So how can i set the features (except set them alphabetically) to be
run in a specific order (like cucumber features -p
run_all_test_suites). Didn't figure it out using tags.
Please advice,
Dan
How can i set cucumber to run features in a specific order ?
I'm using cucumber and watir-webdriver for automated acceptance tests
and i have 3 servers on which the tests run (dev, qa etc). The tests
are cyclic meaning, for, e.g a user is created, posts some stuffs do
some actions and at the end the user is deleted with all his test data
and i can't really use default data on all the servers. I know that
this is not a good approach, features to be dependent on each other
but i'll stick for the moment with this.
So how can i set the features (except set them alphabetically) to be
run in a specific order (like cucumber features -p
run_all_test_suites). Didn't figure it out using tags.
Please advice,
Dan
aslak hellesoy
Feb 28, 2011, 6:31:31 PM2/28/11
to cu...@googlegroups.com, Dan Claudiu Pop
Cucumber will sort files according to their file name before running
them. Just give the file names names accordingly.
Relying on a specific ordering is something we strongly discourage, so
we don't provide an easier way than this to accomplish it.
Aslak
> Please advice,
> Dan
>
> --
> 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.
>
>
Tim Walker
Feb 28, 2011, 8:56:24 PM2/28/11
to cu...@googlegroups.com, aslak hellesoy, Dan Claudiu Pop
Understood that this(relying on test execution order) is not popular
as a general approach, and with good reason, generally. That said, I
am just as certain that there will be times where this could be the
most appropriate way to write complex acceptance scenarios. I've been
toying implementing the following feature (which would be trivial to
implement but haven't yet because I get the feeling Aslak would fly
all the way out here and kick my butt!).
as a general approach, and with good reason, generally. That said, I
am just as certain that there will be times where this could be the
most appropriate way to write complex acceptance scenarios. I've been
toying implementing the following feature (which would be trivial to
implement but haven't yet because I get the feeling Aslak would fly
all the way out here and kick my butt!).
Given the following features run in order
| Workflow Domain Setup Feature |
| Workflow Initiation Feature |
| Acceptance #1 Feature |
| Acceptance #2 Feature |
| Acceptance #n Feature |
Well, you get the drift. Thoughts?
FWIW YMMV,
Tim
Matt Wynne
Mar 1, 2011, 3:01:22 AM3/1/11
to cu...@googlegroups.com
Try just passing the features to the cucumber command in the order you want to execute them. I think Joseph Wilk added this last year some time.
Dmitriy Korobskiy
Mar 4, 2011, 5:34:04 PM3/4/11
to cu...@googlegroups.com
It should be possible to avoid this problem via a combination of data
setup and a "lazy execution".
I'm personally not doing DB-level data setup yet (I'm relatively new to
Cucumber), but I'm doing lazy execution to avoid any ordering problems.
setup and a "lazy execution".
I'm personally not doing DB-level data setup yet (I'm relatively new to
Cucumber), but I'm doing lazy execution to avoid any ordering problems.
----
Background: An open, active cart
Given that I have created a cart
Scenario: Foo
[skipped]
Scenario: Bar
[skipped]
----
Given /^that I have created a cart$/ do
if !defined?(@@carts_created)
When %(I create a new cart)
end
@@active_cart.should_not be_nil
end
In the Given step, I execute "I create a new cart" step, but only once
per Cucumber session. I use class variables to track the state between
Cucumber scenarios.
You could do a similar thing with your Setup Feature. Execute required
data setup lazily and track this fact in some class variables.
--
DK
AIM: DKroot1, Skype: DKroot
Andrew Premdas
Mar 5, 2011, 12:32:06 PM3/5/11
to cu...@googlegroups.com
On 1 March 2011 01:56, Tim Walker <walk...@gmail.com> wrote:
Understood that this(relying on test execution order) is not popular
as a general approach, and with good reason, generally. That said, I
am just as certain that there will be times where this could be the
most appropriate way to write complex acceptance scenarios.
err no!
I've been
toying implementing the following feature (which would be trivial to
implement but haven't yet because I get the feeling Aslak would fly
all the way out here and kick my butt!).
Given the following features run in order
| Workflow Domain Setup Feature |
| Workflow Initiation Feature |
| Acceptance #1 Feature |
| Acceptance #2 Feature |
| Acceptance #n Feature |
Well, you get the drift. Thoughts?
FWIW YMMV,
So what criteria is this testing, If you can't name it and describe it then why the heck are you testing/specifying it. If you can name it then just do
Given my criteria is matched
When you implement the step definition for this just call the code that does your other stuff (don't use nested steps)
e.g.
/^Given my criteria is matched$/ do
setup_workflow_domain
initiate_workflow
accept_feature_1
...
end
Again this assumes you can name and describe the exisitng features to make the correct call.
Now you have one feature that tests/specifies what you want and has no requirement to run other features in a particular order
HTH
Andrew
--
------------------------
Andrew PremdasAndrew Premdas
Mar 5, 2011, 12:34:54 PM3/5/11
to cu...@googlegroups.com
On 4 March 2011 22:34, Dmitriy Korobskiy <dkr...@gmail.com> wrote:
It should be possible to avoid this problem via a combination of data setup and a "lazy execution".
I'm personally not doing DB-level data setup yet (I'm relatively new to Cucumber), but I'm doing lazy execution to avoid any ordering problems.
----
Background: An open, active cart
Given that I have created a cart
Scenario: Foo
[skipped]
Scenario: Bar
[skipped]
----
Given /^that I have created a cart$/ do
if !defined?(@@carts_created)
When %(I create a new cart)
end
@@active_cart.should_not be_nil
end
Yuk! the nested step police have been alerted!!!
How about
Given /^that I have created a cart$/ do
create_cart
end
end
def create_cart
@cart ||= ...
end
All best
Andrew
--
------------------------
Andrew PremdasDmitriy Korobskiy
Mar 7, 2011, 2:54:34 PM3/7/11
to cu...@googlegroups.com
On 3/5/11 12:34 PM, Andrew Premdas wrote:
Given /^that I have created a cart$/ do
if !defined?(@@carts_created)
When %(I create a new cart)
end
@@active_cart.should_not be_nil
end
Yuk! the nested step police have been alerted!!!
Where is the law against reusing step defs? :)
I can, of course, refactor the entire step def. into a helper method, but why? What does it buy me?
I can, of course, refactor the entire step def. into a helper method, but why? What does it buy me?
Andrew Premdas
Mar 8, 2011, 10:01:42 AM3/8/11
to cu...@googlegroups.com
On 7 March 2011 19:54, Dmitriy Korobskiy <dkr...@gmail.com> wrote:
Where is the law against reusing step defs? :)
On 3/5/11 12:34 PM, Andrew Premdas wrote:Given /^that I have created a cart$/ do
if !defined?(@@carts_created)
When %(I create a new cart)
end
@@active_cart.should_not be_nil
end
Yuk! the nested step police have been alerted!!!
I am the law ;)
I can, of course, refactor the entire step def. into a helper method, but why? What does it buy me?
The ability to avoid nesting the step "Given that I created a cart" and replace the nesting with the call to create_cart. This makes your steps much cleaner.
-- DK AIM: DKroot1, Skype: DKroot
--
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.
Dmitriy Korobskiy
Mar 8, 2011, 12:09:38 PM3/8/11
to cu...@googlegroups.com
On 3/8/11 10:01 AM, Andrew Premdas wrote:
On 7 March 2011 19:54, Dmitriy Korobskiy <dkr...@gmail.com> wrote:
Where is the law against reusing step defs? :)
On 3/5/11 12:34 PM, Andrew Premdas wrote:Given /^that I have created a cart$/ do
if !defined?(@@carts_created)
When %(I create a new cart)
end
@@active_cart.should_not be_nil
end
Yuk! the nested step police have been alerted!!!
I am the law ;)
All right, but I'm not sure I'm ready to become a subject.
I can, of course, refactor the entire step def. into a helper method, but why? What does it buy me?
The ability to avoid nesting the step "Given that I created a cart" and replace the nesting with the call to create_cart. This makes your steps much cleaner
I think that the change does not buy any clarity.
"When %(I create a new cart)" or "create_cart" are both pretty clear. create_cart is less verbose, but that's about the only plus I can see.
Let's talk about minuses of extracting all those helper methods.
I'm using a slightly tweaked library of Watir matchers (https://github.com/napcs/cucumber_watir).
watir_steps,rb has a bunch of step defs, for example:
# Find image by alt and click it
### [image] When I click the "Apply now" image
When /^I click the "(.*)" image$/ do |alt|
our_image = @@browser.image(:alt , alt).click
end
When I want to reuse this code now (and stay DRY) I simply do:
When %(I click the "New Cart" image)
If I were to follow you law, I would have to extract a helper method from every single step def in watir_steps,rb that I want to use.
Yes, I can do it, but it'll about double the code size of watir_steps.rb.
In programming, all problems are solvable by introducing a new level of abstraction, except the problem of too many levels of abstractions. :)
"When %(I create a new cart)" or "create_cart" are both pretty clear. create_cart is less verbose, but that's about the only plus I can see.
Let's talk about minuses of extracting all those helper methods.
I'm using a slightly tweaked library of Watir matchers (https://github.com/napcs/cucumber_watir).
watir_steps,rb has a bunch of step defs, for example:
# Find image by alt and click it
### [image] When I click the "Apply now" image
When /^I click the "(.*)" image$/ do |alt|
our_image = @@browser.image(:alt , alt).click
end
When I want to reuse this code now (and stay DRY) I simply do:
When %(I click the "New Cart" image)
If I were to follow you law, I would have to extract a helper method from every single step def in watir_steps,rb that I want to use.
Yes, I can do it, but it'll about double the code size of watir_steps.rb.
In programming, all problems are solvable by introducing a new level of abstraction, except the problem of too many levels of abstractions. :)
Reply all
Reply to author
Forward
0 new messages