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

Implement unambiguous keywords #2043

Open
mattwynne opened this issue May 25, 2022 · 6 comments
Open

Implement unambiguous keywords #2043

mattwynne opened this issue May 25, 2022 · 6 comments
Assignees
Labels
✅ accepted The core team has agreed that it is a good idea to fix this ⚡ enhancement Request for new functionality

Comments

@mattwynne
Copy link
Member

mattwynne commented May 25, 2022

As described in cucumber/common#768

@mattwynne mattwynne changed the title Implement unambiguous keywords in cucumber-js Implement unambiguous keywords May 25, 2022
@davidjgoss
Copy link
Contributor

davidjgoss commented May 26, 2022

Cool, I'm in favour of this proposal.

We have an issue in cucumber-js which is that you can define a step with a generic function called defineStep which is on the public API, and the Given, When, and Then functions are just aliases of that. So at the moment it's kind of ambiguity all the way down, and we'll need to fix that for this to work.

What I'd propose in order to get this to a point where we have an on/off flag for unambiguous keywords is:

  1. (ASAP) support: record step keyword, deprecate defineStep #2044
    • Start recording the keyword used to define steps
    • For defineStep, just record it as "Given" in the interim
    • Deprecate defineStep on the public API
  2. (whenever)
    • Add the option to fail as ambiguous if the keyword doesn't match between source and step definition
  3. (9.0.0 (in a couple months))
    • Remove defineStep from the public API

One thing we should discuss is how the option should be surfaced. We already have strict mode, I would see this as another facet of that but that would be a breaking change since strict mode is on by default. I do believe this is a good default for Cucumber, it's just how best to roll that out.

@davidjgoss davidjgoss added ✅ accepted The core team has agreed that it is a good idea to fix this ⚡ enhancement Request for new functionality labels May 26, 2022
@davidjgoss davidjgoss self-assigned this May 29, 2022
@charlierudolph
Copy link
Member

For 2, I think could have an option --strict-keywords.

If we eventually merge this into strict, I'd think the following would be my eventual ideal (where strict is default for both)

  • --no-strict-pending-steps / --strict-pending-steps
  • --no-strict-keywords / --strict-keywords

Think it would be better with separate options flags so users can opt out of things they don't care about (but don't opt out of extra behavior they are okay with at the same time)

@davidjgoss
Copy link
Contributor

@mattwynne I think this might be a good candidate for the new contributors ensemble. It's not super heavy in terms of complexity but would touch a lot of different parts of the codebase and give a good mapping of the architecture. What do you think? I'd be happy to draft a feature file so there's somewhere to start.

@iomedico-beyer
Copy link

I am against the removal of defineStep from the public API.

Your idea works nicely for the English language, but not for some other. In German, the sentence structure after Dann (German for Then) is different than after Und (German for And). Thus I cannot replace all German And with German Then. It just looks broken. As a workaround, I currently map German And to defineStep.

@iomedico-beyer
Copy link

While I still think defineStep should not be removed (see above), I like the idea of these optional two strict validation modes (to fail fast) - even more so since we recently converted all our tests to English. Any idea when this might be implemented?

@davidjgoss
Copy link
Contributor

davidjgoss commented Jan 17, 2023

@iomedico-beyer thanks for highlighting that perspective on the German language.

At this point it looks unlikely we will enforce strict keywords, at least any time soon if ever. So we could keep defineStep and it would just have to throw if called with the strict option on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✅ accepted The core team has agreed that it is a good idea to fix this ⚡ enhancement Request for new functionality
Projects
Status: In Progress
Development

No branches or pull requests

4 participants