Option do define feature order without workaround

[Pankraz76]

please add the possibility to define hard coded execution oder as last workaround. its not hard to implement and wont break general approach that tests need to be independent 💯 right.

As always there might be an exception in case of an initial password change its mandatory that the update password scenario runs first. As otherwise all the other tests would need to deal with this situation too and thats not practicable.

Please implement the feature options they are interpreted all over the internet even tho it has not any effect at all, to define multiple feature blocks. Still the ugly number_prefix workaround must be used to workaround this special case...

Desired solution:

Actual workaround:

https://forum.katalon.com/t/how-to-run-multiple-feature-files-in-a-specific-sequence-using-cucumber-runner-class/24327

[aslakhellesoy]

please add the possibility to define hard coded execution oder as last workaround. its not hard to implement and wont break general approach that tests need to be independent 💯 right.

Please submit a pull request if you want to see this added to Cucumber.

[mpkorstanje]

Given that @punkratz312 is using cucumber-serenity rather then cucumber-jvm I reckon this request is addressed to the wrong project.

I also don't think this feature is desirable. It will be rather complicated and counter-intuitive to explain and document how this order will be resolved. For example:

com/example/feature-001.feature
com/example/ #contains features 01-999
com/example/feature-099.feature

This creates the suggestion that feature 001 should go first and feature 099 last, and all other features 002-098, 100-999 in between. But because is 099 part of com/example/ is clearly shouldn't go last.

Finally the use case for this feature also isn't something we're looking to support. The assumption is that scenarios are independent. The typical solution to the problem is to create a new account for each scenario -- preferably through an API to speed things up. When real world resources are involved it is not always possible to make scenarios truly independent but the complexity of dealing with that should be dealt with by the user rather then framework.

One approach here would be to bring the account in a usable state once before it is used.

static boolean passwordReset = false;

@Before
public void resetPassword(){
  if(passwordReset){
   return;
  }
  // reset password here
  
  passwordReset = true;
}

And some of this complexity will go away once #1876 is released.

[Pankraz76]

Thanks for the suggestion I will give it a try

…

Sent from my iPhone

On 13. May 2021, at 17:02, M.P. Korstanje ***@***.***> wrote:  Given that @punkratz312 is using cucumber-serenity rather then cucumber-jvm I reckon this request is addressed to the wrong project. I also don't think this feature is desirable. It will be rather complicated and counter-intuitive to explain and document how this order will be resolved. For example: com/example/feature-001.feature com/example/ #contains features 01-999 com/example/feature-099.feature This creates the suggestion that feature 001 should go first and feature 099 last, and all other features 002-098, 100-999 in between. But because is 099 part of com/example/ is clearly shouldn't go last. Finally the use case for this feature also isn't something we're looking to support. The assumption is that scenarios are independent. The typical solution to the problem is to create a new account for each scenario -- preferably through an API to speed things up. When real world resources are involved it is not always possible to make scenarios truly independent but the complexity of dealing with that should be dealt with by the user rather then framework. One approach here would be to bring the account in a usable state once before it is used. static boolean passwordReset = false; @before public void resetPassword(){ if(passwordReset){ return; } // reset password here passwordReset = true; } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.