Cucumber Tables

Testing RSpec
1

I am running into this situation:

Feature 1

Scenario A
…
Then we should have currency exchange rates for “USD” on file
And we should …

Feature 2

Scenario D
…
Then we should have currency exchange rates for “USD” on file
| code|
|“EUR”|
|“JPY”|
|“KRW”|
|“MXN”|
And we should not …

This arrangement presently gives a cucumber error because the step
definition that matches will either have one argument too many or one
too few. However, from a user point of view it strikes me that this
situation should not be an error at all.

My reasoning is this. The features statement as given is completely
logical, straight-forward and applicable in either situation. Having a
requirement to create separate invocations for exactly the same test,
depending only upon whether one wishes to do it once or several times,
strikes me as bending the situation to the limitations of the
implementation rather than elaborating the implementation to handle the
situation.

On the other hand, as this may be quite involved to solve I am not
saying what I suggest MUST be the behavior, only that it seems to me
that it should be.

I seem to recall that when I first used cucumber in December last, that
one could either provide additional examples to a matcher in a scenario
or not. In either case the matcher would work. I think that this
behaviour, if at all possible, might be more natural than requiring two
separate matchers that exist only to match to different patterns.

What do you all think?

2

Feature 2

This arrangement presently gives a cucumber error because the step
definition that matches will either have one argument too many or one
too few. However, from a user point of view it strikes me that this
situation should not be an error at all.

My reasoning is this. The features statement as given is completely
logical, straight-forward and applicable in either situation.

A common way to express step definitions that take multiline arguments
is to explicitly refer to the multiline argument in the step text. For
example:

Then I should have the following shoes:
|size|model|
|43 |Adidas Oslo|
|41 |Nike Racer|

If you don’t do this, the multiline argument is “dangling”. Steps that
take multiline arguments should be formulated in such a way that
removing the multiline argument makes the sentence nonsensical. This
is not the case for your example. Remove the table and the sentence
still makes sense. That’s very confusing. In fact, sticking a table
onto that sentence makes no sense at all to me. I have to guess how
that table is related to the sentence above it. Be explicit, and
you’ll save yourself a lot of headache.

In your case I would do this:

Then we should have currency exchange rates for “USD” on file

Then we should have currency exchange rates for “USD” on file with the
following codes:
| code|
|“EUR”|
|“JPY”|
|“KRW”|
|“MXN”|

Aslak

3

Aslak Hellesøy wrote:

If you don’t do this, the multiline argument is “dangling”. Steps that
take multiline arguments should be formulated in such a way that
removing the multiline argument makes the sentence nonsensical.

Yes, I understood that. And I also realized that the solution is to
have two separately phrased matcher clauses. However, this approach
does strike me as incongruous with cucumber’s philosophy of reading
naturally.

Consider this situation.

Iteration 1 to 5

Then we should have currency exchange rates for “USD” on file

Iteration 6

Then we should have currency exchange rates for “USD” on file with the
following codes
| code|
|“EUR”|
|“JPY”|

Now, besides begin awkwardly worded, “rates for “USD” on file with the
following codes” (which admittedly could be repaired with some thought),
this requires that an additional matcher be provided in the step
definition file. Further, the similarity of phrasing is an invitation
to a matcher collision. I rather suspect that in these cases this is
what will end up in the feature files on most occasions:

Then we should have currency exchange rates for “USD” on file
Then we should have currency exchange rates for “EUR” on file
Then we should have currency exchange rates for “JPY” on file

This requires far less work as the matcher already exists and one need
only replace six characters after a couple of cut and pastes.

Presently, the table method works best, I think, when it is employed
from the outset. However, when things are elaborated after the initial
matchers are written then it seems more work than it is worth to
duplicate existing matchers just to cut down somewhat on boilerplate in
the feature files.

If, instead, one could just add a table under an existing step matcher
then this would be more in keeping with what cucumber does so well
elsewhere, extend features and scenarios naturally and effortlessly.

Then we should have currency exchange rates for “USD” on file
| code|
|“EUR”|
|“JPY”|

This is more user friendly because it creates far less of an
intellectual load (having to devise a new wording for an existing phrase
and implementing same as a special case) than simply extending the
existing structure.