Gherkin: documentation for semantics of `Rule` keyword

[bbqsrc]

Other than #416, I haven't been able to find any documentation about the Rule keyword and its expected children elements, nor what "Gherkin 6" is to consist of. Has this yet been documented anywhere?

[aslakhellesoy]

@bbqsrc Gherkin 6 isn't released yet, nor is it integrated into any Cucumber implementations yet. It's my primary focus at the moment.

You will find more background in #250, which is the issue that prompted the addition. The changes in Gherkin 6 will be finalised when we make a new release. I might as well start here though:

Rule keyword

The new optional Rule keyword is optional. Older Gherkin documents without Rule keywords are still valid.

The Rule keyword is simply a grouping construct. It can be used to group Scenarios that are related to the same Rule. This makes it possible to represent an example map in a Gherkin document. Some people may want to replace Scenario with Example (a new synonym to Scenario) to make Gherkin documents even more closely aligned with example mapping.

Scenario Outline = Scenario

It is now possible to place Examples tables under a regular Scenario. When you do, the scenario is executed several times, replacing <> tokens with values from each Examples row. The Scenario Outline keyword is now just a synonym for Scenario.

UTF-8

Previous versions of Gherkin made it possible to specify an alternate encoding for .feature files using a header such as # encoding: ISO-8859-1. This is no longer possible. All Gherkin documents must be UTF-8 encoded.

[bbqsrc]

Thanks for that information. It seems so far I have been on track with how Rule is meant to behave, and Scenario Outline = Outline, in the Rust implementation of Cucumber and Gherkin I've been working on.

I will do my best to follow Gherkin 6 as it continues to emerge. 😄

[aslakhellesoy]

Oooh a Cucumber-Rust would be amazing!

I recommend you take a look at the Cucumber roadmap.

All the official Cucumber implementations will use gherkin-go (over protobuf). A full Cucumber implementation has several components (gherkin, cucumber-expressions, tag-expressions, datatable, formatters etc).

To reduce the amount of code that needs to be implemented (and maintained) we're working on a cucumber-engine in Go. This will make it easy to write a new Cucumber implementation in any language.

Would you consider joining us on this roadmap?

[bbqsrc]

Thanks for your kind remarks. 😄

Based on my reading of the roadmap though I see no reason the cucumber-rust project could not be compatible with gherkin-go as well as gherkin-rust prior to reaching v1.0.0. And utilising protobuf in Rust is a delight so that will be an absolute non-issue.

I would say that my Rust implementation is unofficial by design as it's not a language that easily takes to this kind of testing, or at least, didn't seem to when I started. At this stage there is rudimentary support for tag expressions, but docstrings and datatables are fully supported already from the Step struct passed to each step closure. Implementing the NDJSON evented AST is on my roadmap as well, as it seems quite straightforward.

As an aside, I do however see a strong academic interest in maintaining a Gherkin parser that takes a different approach to the primary project to avoid situations like the Ruby MRI "the C implementation is the spec" approach to parsing the language (of course Gherkin is simpler than the Ruby language but I'm sure you can appreciate the analogy). I will continue to implement the features described by the emerging Gherkin 6 as a side-project.

[aslakhellesoy]

Ok, sounds good. The NDJSON representation of messages is only used for gherkin's approval tests. Inter-process communication (e.g. Java requesting Gherkin ASTs and pickles from gherkin-go) will use protobuf.

As for the Gherkin grammar spec - it's in gherkin.berp. The parser generator is berp, which we built to support several languages. Now that we're only targeting Go, we could use a standard parser generator (or even hand-write a recursive descent parser - it's a simple grammar), but we don't see a need to - it's working.

[bbqsrc]

Is there a more appropriate venue to discuss these kinds of things or is GitHub the place?

On 12 Aug. 2018 at 18:34, <Aslak Hellesøy [email protected]> wrote:

Ok, sounds good. The NDJSON representation of messages is only used for gherkin's approval tests. Inter-process communication (e.g. Java requesting Gherkin ASTs and pickles from gherkin-go) will use protobuf.

As for the Gherkin grammar spec - it's in gherkin.berp https://github.com/cucumber/cucumber/blob/master/gherkin/gherkin.berp. The parser generator is berp, which we built to support several languages. Now that we're only targeting Go, we could use a standard parser generator (or even hand-write a recursive descent parser - it's a simple grammar), but we don't see a need to - it's working.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cucumber/cucumber/issues/453#issuecomment-412354800, or mute the thread https://github.com/notifications/unsubscribe-auth/AARCOzjRXZ4xQhPDDRUhNwjF9NJA2EjVks5uQFkXgaJpZM4V0f1j .

[aslakhellesoy]

Is there a more appropriate venue to discuss these kinds of things or is GitHub the place?

Yes, the #committers channel in Slack. See https://cucumber.io/support for details about how to join.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[aurelien-reeves]

@aslakhellesoy @bbqsrc what about that issue? It seems outdated to me:

• gherkin-go has not been used as the only gherkin implementation, and wont be
• protobuf is not a thing anymore
• the rule keyword is now well supported

@bbqsrc do you still need it?

PS: last time I looked at cucumber-rust, it looked pretty nice! Well done! 👏