Closed Hsilgos closed 1 year ago
I do like the idea of adding configuration for this. CucumberSwift configuration is an inconsistent mix of Swift and plist values.
How would you feel about adding a defaulted variable to the StepImplementation protocol that contained at least this and perhaps other values? They'd have to still work as they are, but it'd give us a place to add new things from now on.
So, something like a CucumberSwift.Config type
In current implementation hooks are called in the order in "whatever order they appear in the code" unless priority is specified.
This is inconsistent with other's implementations like cucumber-jvm. Documentation for
@Before
in cucumber-jvm:Documentation for
@After
in cucumber-jvm:As you see order has opposite meaning for
@Before
and for@After
. Also articles say that order of execution is reversed for "@After" hooks, for example https://www.axelerant.com/blog/how-work-cucumber-hooks#H3140 For the same priority (or for absence of priority)@After
is called in reversed to registration order.So basically for code
The order must be
Before 1.1 -> Before 1.2 -> Before 2 -> Scenario -> After 2 -> After 1.2-> After 1.1
Pay attention that After hook with higher priority is called first and After hook with the same priority are called in reversed (to declaration sequence) order.
Why is it important?
I build more complex logic where steps are grouped by functionality, so it rather look like:
As I told I want the order Bar.BeforeScenario -> Foo.BeforeScenario -> Scenario -> Foo.AfterScenario -> Bar.AfterScenario In this simple example I can use parameter
order
, but when I have many such classes in many files it became problematic and error prune to specify order everywhere.Necessary change looks easy, but breaks existing code. How about to introduce an option like
continueTestingAfterFailure
which changes this behaviour?reverseOrderForAfterHooks
?