AST for Example Placeholders and implicit Step Parameters

[muhqu]

I was wondering why the gherkin parser doesn't parse example-placeholders e.g. <name> or implicit/default step parameters e.g. numerics or quoted strings...

Sure, I understand that the interpretation of the Step's text is not part of gherkin, but that of the step definition provider or test suite runner (e.g. cucumber, behat etc...). But I think it would be good for tools like linters, syntax highlighters, etc to identify all meaningful parts of the gherkin file...

Also example placeholders could be verified against the examples table headers.

What do you think?

---

…here are some examples

Feature: Consuming Cucumbers

  Scenario: eat 5 out of 12
    Given there are 12 cucumbers
     When I eat 5 cucumbers
     Then I should have 7 cucumbers

  Scenario Outline: eating
    Given there are <start> cucumbers
     When I eat <eat> cucumbers
     Then I should have <left> cucumbers

    Examples: 
      | start        | eat | left   |
      |           12 |   5 |      7 |
      |         20.9 |   5 |     15 |

Feature: Hello World

  Scenario: Nice people
    Given a nice person called "Bob"
      And a nice person called "Lisa"
     When "Bob" says to "Lisa": "Hello!"
     Then "Lisa" should reply to "Bob": "Hello!"

[gasparnagy]

Example placeholders: It would be hard to fit this to the current parser concept. But the compiler will do this (see #12)

Implicit/default step parameters: they are only heuristics and the exact parameters cannot be inferred automatically by analyzing the text. So I think these should not be parsed by gehrkin3.

[aslakhellesoy]

Implicit/default step parameters: they are only heuristics and the exact parameters cannot be inferred automatically by analyzing the text. So I think these should not be parsed by gehrkin3.

Agree. The presence of a number or double quotes doesn't imply parameters. It's just a convention that Cucumber uses when it generates step definitions.

I often use parameters without quotes - because I think it reads better. Of course, Cucumber isn't able to guess where the params are when it prints a stepdef snippet, but that's fine - I'll just write the regexp by hand.

[aslakhellesoy]

Regarding representing <name> in the AST - it would be nice in theory, but I think it would complicate the parser a lot, and I'm quite happy only dealing with them in the compiler.

Did we answer your questions @muhqu ?

[muhqu]

I agree that handling quotes and numerics in the Step text is beyond the scope of what the gherkin parser should deal with.

But I think it would be a great (if not mandatory) addition to represent <placeholders> in the AST.

I'm not that sure I understand what the 'compiler' is all about yet. But if one use case for it would be to transform the gherkin AST to something more generic, e.g. flattening Scenario Outlines, it would be helpful if the AST represents the placeholders.

@aslakhellesoy yea, sure it answers my question.

[aslakhellesoy]

The compiler is described in the root README as well as in #12. If you have specific questions about what it is/why it's needed, let's carry on in #12.