-
-
Notifications
You must be signed in to change notification settings - Fork 690
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
Change messages and Gherkin parser/pickle compiler to retain step keyword #1741
Conversation
fd1d331
to
04f3941
Compare
It looks promising 👍 Is the "non-keyword" Feature: a feature
Scenario: a scenario
* first step
* second step |
Yes. The "non-keyword" is missing. If you look at you'll see that the |
Good question for our community meeting 😁 |
So, in preparation of that meeting, I took a stab at the Ruby parser, trying to find whether it supports the which suggests that it also doesn't. So, definitely something to discuss! |
My take on the "*" keyword is that when using it, the step should be allowed to match step definitions defined with all of "Given", "When", and "Then". From the original discussions of "unambiguous keywords", I think I remember the view that defining both step definitions for "Given " and "When " should (still?) be an error, so the keywords in the pickles should rather be for verifying the keyword of the step definition, than for selecting one of several candidates of step definitions. |
As long as the "* " keyword is defined in the gherkin-languages.json is is supported, isn't it? |
I would suggest deferring this to a the cucumber implementation. It's non trivial, especially with |
This is how |
|
Yeah |
On the other hand, we realized with @sebrose that treating So if we do this change it would be good if we could semantically detach the |
I think the intent was to have this as well as the verbatim keyword, not instead? |
The "* " is a valid keyword for Given, When, Then, And, But (see gherkin-languages.json). So any parser that passes the test supports "* " (see this ast.ndjson). Currently its not a problem that "* " is a valid keyword for all types, but when converting to G/W/T then the question of how to convert "* " occurs. My suggestion in that case, it should be converted to the "*" type (which would be valid for all step definitions). |
When we refer to the "phase" of the scenario, the thing that's called I suggest we make this an enumerable with the values:
We can map I am still curious about where we would put that logic so that all implementations can do it consistently. I think it's clearer to avoid the English Gherkin keywords (Given, When, Then) here, so this stands out as being a distinct thing from the keyword used in the document. Edit: I think |
@gasparnagy writes:
I'd agree that a scenario of pure conjunctions (And / But) doesn't look good. However, if I'm understanding correctly the way Cucumber Ruby/Java work now, it's still allowed. To that extent, I'd say that the argument @mpkorstanje and @mattwynne (?) made to leave the intepretation of the keywords to the actual executor and not hard-code it in the Pickle compiler, does allow the executor to object to scenarios like these (or simply assume "* ").
I think that if I change the PR to have the same fields |
@mattwynne I disagree with that |
I like the abstraction of phase suggested my @mattwynne. What about these?
|
Good point. In fact we might find (now or in the future) that there are other strings mapped in the gherkin language spec that could be mapped back to more than one keyword. |
Assuming that more of these exist today, should all of these be mapped to "General" in that case? Doing so will at least give us the desired behaviour for |
All that's going on here really is the implementation of a change in |
Last call for discussion and/or objection Are we good? Can we merge? Are we still waiting for something else? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
We did not specify a version range for the Cucumber::Messages dependency. This wasn't a problem before, every version of message was usable. However once cucumber/common#1741 was merged this was no longer true. Fixes #48
We did not specify a version range for the Cucumber::Messages dependency. This wasn't a problem before, every version of message was usable. However once cucumber/common#1741 was merged this was no longer true. Fixes #48
We did not specify a version range for the Cucumber::Messages dependency. This wasn't a problem before, every version of message was usable. However once cucumber/common#1741 was merged this was no longer true. Fixes #48
Summary
Re #768: As discussed, for further discussion, implement a proposal for retention of step keywords Given/When/Then/But/And into the pickle.
Please note that the tests on this PR can't succeed until the test-data has been patched to include the new fields defined in the JSON schema. I'll take that task when the general direction has been decided to be acceptable/refined.
Details
Considerations (summarized from the issue as well as implementation-wise):
But
andAnd
are resolved to theGiven
/When
/Then
keywords they inherit their context from, because:But
andAnd
keywords have been resolved to eliminate variability in intepretationkeyword
) and the key as it is used in the translations (Given/Then/When/And/But).Motivation and Context
Screenshots
Not screenshots, but rendered output nonetheless.
(the first scenario of the) AST output from
gherkin --predictable-ids --no-source --no-pickles testdata/good/i18n_fr.feature
:And the pickle output for said first scenario (
gherkin --predictable-ids --no-source --no-ast testdata/good/i18n_fr.feature
):See the lines with the
******
markers for the new output.How Has This Been Tested?
It's only lightly tested, because this is mostly for discussion purposes.
Types of changes
Checklist:
@aslakhellesoy indicated this PR should not be blocked on the
.NET
implementation, as it's not ported to JSONSchema yet (still running on the old protobuf schema).