Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Stricter step definition registry and consequently removal of And and But #263

Closed
badeball opened this issue Oct 22, 2019 · 2 comments

Comments

@badeball
Copy link
Owner

badeball commented Oct 22, 2019

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.

@badeball
Copy link
Owner Author

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.

@lgandecki
Copy link
Collaborator

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants