Make data tables taggable (and possibly example table rows)

[jfinkhaeuser]

Relating to my comment on cucumber/cucumber-ruby#821 about locale testing, if you run tests across multiple locales, data and example tables lend themselves to separating functional descriptions (steps) from locale-specific data (tables):

Feature: foo

  Scenario Outline: do something
    Given I see a button labelled "<button>" # bad step, ignore please

    @en
    Examples:
      | button   |
      | click me |

    @de
    Examples:
      | button     |
      | klick mich |

So far, so good. I love example tables and tagging for this :)

The problem occurs when you have to repeat the same action multiple times:

Feature: foo

  Scenario Outline: do something
    Given I see a button labelled "<button1>"
    And I see a button labelled "<button2>"

    @en
    Examples:
      | button1  | button2 |
      | click me | me too  |

    @de
    Examples:
      | button1    | button2   |
      | klick mich | mich auch |

The approach doesn't scale well beyond a few repetitions, and really doesn't help with the "push how down" concept. A much better approach would be to group these into a single step:

Feature: foo

  Scenario: do something
    Given I see a few buttons button labelled "<button>"
      | button   |
      | click me |
      | me too   |

Unfortunately, you can't do this with locales:

Feature: foo

  Scenario: do something
    Given I see a few buttons button labelled "<button>"
      | button   |
      @en
      | click me |
      | me too   |
      @de
      | klick mich |
      | mich auch  |

Unfortunately, I don't like the syntax very much like this. An alternative example would be:

Feature: foo

  Scenario: do something
    Given I see a few buttons button labelled "<button>"
      @en
      Data:
        | button   |
        | click me |
        | me too   |
      @de
      Data:
        | button     |
        | klick mich |
        | mich auch  |

The Data keyword would then be optional if no tags are used. Though I'll admit that might make the grammar trickier :-/

[jfinkhaeuser]

Ah. I forgot to mention. The first syntactical approach could be applied to example tables, the second approach is in fact how example tables work right now.

[enkessler]

Yeah, I don't like the first syntax either. Half the point of the Examples/Data part is using it to describe why the following rows are different instead of having seemingly random tags thrown in.

I thought that someone had already raised the possibility of having datatables be a thing that could be in an example row (and that would achieve the effect that you are going for) but I'm not finding anything in the existing Issues or the Google Group.

Edit: Closest thing that I've found is #52

[aslakhellesoy]

I don't want to add tags on individual table rows. I want Gherkin editors (especially web-based ones) to be able to use standard grid/table components. That becomes hard when there are tags involved.

I really don't like the proposed Data: syntax for data tables. Too complicated. I want Gherkin to be simple and accessible to non-technical people. I think you're making it difficult and complex.

[aslakhellesoy]

This has been proposed before in #142 - and rejected

[enkessler]

Um, reading through that thread it sounds like you came back around and were willing...

[aslakhellesoy]

It's not a hell yeah from me. I'm still not sure how it would be rendered in a table widget.

[jfinkhaeuser]

Well, the proposals are one thing, the use cases are another: I keep running into this kind of usage in practice, unfortunately, and haven't found a better way to solve it in Gherkin.

[enkessler]

Until something better comes along, you could always go with

Feature: foo

  Scenario Outline: do something
    Given I see "<buttons>"


    @en
    Examples:
      | buttons            |
      | click me ; me too  |

    @de
    Examples:
      | buttons                |
      | klick mich ; mich auch |

and let the step definition split the group into individual button checks.

[aslakhellesoy]

Scenario Outline was meant to be a mechanism for permutation testing by creating many scenarios from one template - and run them all in the same run.

You're using it as a mechanism to parameterise a single scenario so you can run it against different applications.

Do you see the difference?

[jfinkhaeuser]

I see the difference, sure. I've commented many times when people abused this too much; my example with button names is such a bad example, as I've commented in the very first example I've given.

My point revolved much more around locale testing, hence the specific example. Particularly with unicode, testing various locales isn't about content (i.e. is this title spelled correctly in Pakistani), but about functionality (does this Korean name get processed properly, i.e. is it mangled if it gets stored in the DB and retrieved at a later date).

That is IMHO an entirely valid use case of Scenario Outline, and could be of data tables - except that's not supported.

[jfinkhaeuser]

@enkessler that is pretty much the hackaround I'm considering. It doesn't sit too well with me predominantly because the table cell data format needs to be understood by the folk writing the feature files, who might not like anything more complex than you propose.

Your proposal fails when you need the semi-colon to be part of the data, which means you need escaping and a slightly more complex parser, and sooner or later somebody's going to say "let's just use JSON" and then non-technical folk are going to be overwhelmed.

Practical, yes, but IMHO not desirable. I'd like to arrive at something that's desirable :)

[jenisys]

Just another thought:
Are you sure you need to solve this problem in Gherkin ?
A Gherkin file is just a text file.
You could easily use a template engine with templates (for Gherkin files) and the locale data for each language to generate a set of Gherkin files, one set for each language.

Not everything needs to be solved in Gherkin.
There are also template engines, build scripts, and so on. I hope you see my point.