You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The And and But keywords of Gherkin seems to primarily exist for the purpose of having a more fluent language when invoking multiple steps of the same type. Hence, it seems nonsensical to me to use them in step definitions, as the step definitions themselves aren't seen in the context of any previous steps.
Furthermore, and perhaps more importantly, I would have liked to have a stricter registry that enforces correct types (ie. that you cannot write Given I should see .. if you've registered such step using Then).
I've observed in several projects now that the readability of tests deteriorates when not every change is strictly reviewed. Having this enforced by the framework would yield faster feedback than what eg. code review could offer.
The text was updated successfully, but these errors were encountered:
After further research, I realise that this behavior is actually in accordance with the Gherkin specification, which state "Keywords are not taken into account when looking for a step definition.". Consequently, I believe this proposal should first make it into Cucumber (posted here) and not until then should cypress-cucumber-preprocessor follow.
This is interesting. I think I like it, but I do agree that it would be great to align with Cucumber in that regard, and have them make the first move.
I'm also not sure how we could introduce it - as it would break a ton of existing testing codebases. I guess we could introduce a major version, but then we wouldn't provide support or updates to people that prefer not to take this leap. At the same time, if cucumber decided to follow that idea, we wouldn't have to be too apologetic about it.
Anyway, for now, let's wait and see what happens in cucumber :)
The
And
andBut
keywords of Gherkin seems to primarily exist for the purpose of having a more fluent language when invoking multiple steps of the same type. Hence, it seems nonsensical to me to use them in step definitions, as the step definitions themselves aren't seen in the context of any previous steps.Furthermore, and perhaps more importantly, I would have liked to have a stricter registry that enforces correct types (ie. that you cannot write
Given I should see ..
if you've registered such step usingThen
).I've observed in several projects now that the readability of tests deteriorates when not every change is strictly reviewed. Having this enforced by the framework would yield faster feedback than what eg. code review could offer.
The text was updated successfully, but these errors were encountered: