Is there a way to control the order of cucumber features?

1
votes

I am using cucumber with java, maven, and testng, on aws device-farm and there is a suite of scenarios I would like to run. I have several different feature files, each contains several tests with the same tag name. I mean that each one of my feature file contains a tag @sanity. When I run it, I see that the tests run according to alphabetical order of the feature files name. Is there a way to control the order of the execution?

For example I have favorites.feature, treks.feature, and chats.feature. Each of these feature files have a test with @sanity tag. I want to be able to run the @sanity test in treks.feature before the @sanity test in chats.feature. Is it even possible?

Thanks

1
javamavencucumbertestngcucumber-java
U can use the order option to run in random, reverse or random with a seed. Check the usage doc. Though only available from command line. – Grasshopper
Thanks for your reply. Is the --order option will give me the ability to run @sanity tags in the order that I want despite those tags are located in different feature file? From what I've read, not sure it will work in my case. – shay n
What order u are looking for? – Grasshopper
I edit my question to be more specific. thanks – shay n
Nope will not work for u. Not a good idea to have dependency between scenarios. If u wanna do it then place the treks.feature in a folder with a name alphabetically before the chats.feature folder name. – Grasshopper

1 Answers

0
votes

Please note that running features in a specific order is not recommended.

From the Cucumber docs: "Each scenario should be independent; you should be able to run them in any order or in parallel without one scenario interfering with another. Each scenario should test exactly one thing so that when it fails, it fails for a clear reason. This means you wouldn’t reuse one scenario inside another scenario. "

Having them depend on each other, will make your suite more flaky and harder to maintain. For example: if module B can only be created if module A is present, the test for that should make sure module A is present. If one scenario is a prerequisite for other scenarios, if that one scenario fails, a lot of the scenarios will fail - even though the other tests might be testing for other things. Analysing failures will take a long time.