Gherkin 3 is taking shape nicely - want to help?

[aslak hellesoy]

TL;DR We'd love some help with Gherkin 3 - and implementations in new platforms/languages!

The earliest versions of Cucumber (2008) used a Gherkin parser implemented with Treetop [1]. It was slooooooow.

In 2009, Greg Hnatiuk and Mike Sassak wrote Gherkin 2, implemented with Ragel [2]. It was fast!! It has served us extremely well.

However, there are several problems with Gherkin 2:

- It's very difficult to build, so releases are very infrequent

- It doesn't work on recent Ruby versions for Windows

- It's hard to add support for new platforms

- It does too much (and not enough)

- Big: One parser for each i18n language

Gáspár Nagy (of SpecFlow fame) has done a tremendous job with Gherkin 3. (I had a failed attempt at Gherkin 3 two years ago).

Gherkin 3 solves all of the problems with Gherkin 2:

- Easy to build

- Works on any Ruby (and JavaScript, .NET and Java/JVM)

- Easy to add support for new platforms

- Ignorant about reporting (not doing too much)

- Compiles the AST to a simpler structure for Cucumber (simplifies Cucumber)

- Small: Single scanner/parser to support all 60+ i18n languages.

- Just as fast as Gherkin 2

So if you want to help out fixing the TODOs or even implement a parser for a new language (Go anyone?) head over to https://github.com/cucumber/gherkin3

Hopefully we'll be able to roll Gherkin 3 into one of the cukes in the next few months.....

Aslak

[Johannes Fahrenkrug]

+1 This is exciting!

[Aslak Hellesøy]

So out of nowhere, one Cucumber's most prolific contributors Björn Rasmusson just pushed Gherkin3 implemented in Python today :-)

As usual your work is outstanding Björn. I went ahead and merged it to master and made a few very minor tweaks.

 

Hopefully we'll be able to roll Gherkin 3 into one of the cukes in the next few months.....

And Björn has made some great headway here in https://github.com/cucumber/cucumber-ruby-core/pull/93

There is still work to be done for the other Cucumber implementations.

There are a few good unofficial Cucumber implementations out there for Python, but they don't use any of the official parsers.

Just like the Gherkin3 project's architecture is thoroughly documented, I'd like to come up with a similar architectural design doc for Cucumber over

at https://github.com/cucumber/cucumber

What I would love to come up with is a document that is specific enough to ensure a consistent behaviour and architecture between all implementations.

The existing Cucumber implementations wouldn't follow it, but it could serve as a blueprint for new implementations, and the existing implementations might move towards it.

What do you think about this idea?

Aslak

 

Aslak

[Paolo Ambrosio]

I think it's a very good idea. I'm a fan of "just enough
documentation", and it should be easy to manage (only major changes
would need to touch it).

Paolo