[Cucumber] Options in tables

In Cucumber I want to remove duplication from my examples tables.
see With duplication removed · GitHub for an example of the type of situation
I
am facing.

I would like the second example to be equivalent to the first.

To do this… I need cucumber to read a row in the examples and notice
the
‘options’, then run it as if it were several rows in the table, one for
each
possible combination of options.

Anyone else find this useful? … or got any suggestions for better ways
of
doing it?

Anyone else find this useful? … or got any suggestions for better ways of
doing it?

  1. See another current thread in this list: [Cucumber] Tables
  2. [new|expired] does not matter, so you don’t need the column at all
    you can put two checks in the step definition, I think.
    perhaps this allows you to write the remaining steps in another way,
    without duplication of steps.

Bye,
Kero.


How can I change the world if I can’t even change myself?
– Faithless, Salva Mea

Hi Kero…

I agree that in defining the rules that define the behaviour those
situations are equivalent.

However, as the examples are the tests we need both as we need to test
both those scenarios so the testers have confidence the feature is
working
in all situations.

It’s being a really good experience in my current project to work so
closely
with the test team. I’m getting some really good feedback.

Cheers
Nigel

2009/4/23 Kero van Gelder [email protected]

sorry… the first point… you’re right this feature is to do with tables
too, however this feature is orthogonal to the other one, so I decided to
start a new thread … I hope that was right.

Sure, just wanted to make sure you’d seen the other thread.

(on a aside note: what would examples look like if both ideas get
implemented? I’m afraid it’ll be confusing.)

I agree that in defining the rules that define the behaviour those
situations are equivalent.

However, as the examples are the tests we need both as we need to test
both those scenarios so the testers have confidence the feature is working
in all situations.

Given I am a
And I am on the entity list screen
When I a new or expired entity

I realize the three Then steps become “double” steps, too.
Doesn’t really scale when you have more than two states…

It scales fine when the state does not matter, no “double” steps
at all.

I’m out of ideas, time for someone else to chime in :slight_smile:

It’s being a really good experience in my current project to work so
closely with the test team. I’m getting some really good feedback.

Cool!

Bye,
Kero.


How can I change the world if I can’t even change myself?
– Faithless, Salva Mea

in all situations.

Given I am a
And I am on the entity list screen
When I a new or expired entity

I realize the three Then steps become “double” steps, too.
Doesn’t really scale when you have more than two states…

oh ok… no. The ‘Then’ steps are still single steps… the scenario gets
executed more times…

so if you had

Example:
| X | Y |
|[a|b]|[c|d]|

The scenario would be run 4 times:
{X=>“a”, Y=>“c”}
{X=>“a”, Y=>“d”}
{X=>“b”, Y=>“c”}
{X=>“b”, Y=>“d”}

I’m really just trying to find a succinct way to express a bunch of
combinations so more paths are covered by the test.

What bothers me is that if I keep applying techniques to reduce the
number
of lines it takes in the example to explain all the combinations in a
succinct way… the next feature would be to have precidence rules for
the
examples lines… and then you in effect have a rules engine! … maybe
that
is the natural extension of the examples table… here are the rules
that
goven this scenario!

If that is the end result… maybe there is a better way to express it
than
as a table (although I am having some good wins with tables at the
moment)

WDYT?

I’m no mathematician, but perhaps there’s some notation from set
theory that could be helpful?

sorry… the first point… you’re right this feature is to do with tables
too, however this feature is orthogonal to the other one, so I decided
to
start a new thread … I hope that was right.
Cheers
Nigel

2009/4/23 Nigel T. [email protected]