Being the author of Cucumber, some of you might be surprised that I ask
this
question:
How should I go about to implement a Cucumber feature and step
definition
with the following data? 1) Religious Menu · GitHub (just look at the first file for now)
Imagine I’m opening a restaurant where customers are asked for their
religion. Based on what they answer, they will be presented with a
tailored
menu. (Apologies in advance if I’m ignorant about what different people
it).
In either case, I’m not happy about the feature and step definitions I
end
up with. The Scenario Outline version has annoying duplication. I have
to
duplicate each meat 3 times! This makes it hard to read and edit. The
multiline step argument version isn’t much better. If a menu for a
religion
is wrong I’ll only get one error, the error won’t tell me what’s wrong
(unless I explicitly craft my error messages in the step definition) and
max
one failure will show (there is only one scenario).
There should be a better way to express this kind of tests. But I’m not
sure
how. Is there a smarter way with the current Cucumber? If not, how would
you like to express this sort of problem?
different people it).
edit. The multiline step argument version isn’t much better. If a menu
for a religion is wrong I’ll only get one error, the error won’t tell
me what’s wrong (unless I explicitly craft my error messages in the
step definition) and max one failure will show (there is only one
scenario).
There should be a better way to express this kind of tests. But I’m
not sure how. Is there a smarter way with the current Cucumber? If
not, how would you like to express this sort of problem?
I think the second way is a better way of expressing the problem, the
output/run strategy is the problem.
What you really want is an examples table that is embedded in a step
(different from a step table, maybe by keyword?) that causes the step to
be run multiple times for each of the values. So rather than using
placeholders we embedded a Examples table in the step.
Just my inital thoughts. I’ll knock together an example and more ideas
when I get home…
different people it).
much better. If a menu for a religion is wrong I’ll only get one
error, the error won’t tell me what’s wrong (unless I explicitly
craft my error messages in the step definition) and max one failure
will show (there is only one scenario).
There should be a better way to express this kind of tests. But I’m
not sure how. Is there a smarter way with the current Cucumber? If
not, how would you like to express this sort of problem?
Cheers,
Aslak
Looking at the forks of your example gist, I think I would have done
it exactly the way mabes suggested. I’m not sure if I can think of a
better way.
I think the scenario outline is the way to go, but in your example
it’s not clear to me what the behavior is supposed to be-- is the
expected output in your Then statement really providing value?
Scenario Outline: Religious menus
Given the customer is “”
When he asks for the menu
Then he should see pork selections if
And he should see lamb selections if
And he should see veal selections if
Scenarios:
| Religion | Pork | Lamb | Veal |
| Christian | Y | Y | Y |
| Jewish | | Y | Y |
| Muslim | | Y | Y |
| Hindu | | Y | |
What you really want is an examples table that is embedded in a
step (different from a step table, maybe by keyword?) that causes
the step to be run multiple times for each of the values. So rather
than using placeholders we embedded a Examples table in the step.
On Tue, Apr 21, 2009 at 7:32 PM, Jonathan L. [email protected] wrote:
On Apr 21, 2009, at 1:57 PM, Joseph W. wrote:
What you really want is an examples table that is embedded in a step
(different from a step table, maybe by keyword?) that causes the step to be
run multiple times for each of the values. So rather than using placeholders
we embedded a Examples table in the step.
like this?
Not quite, I was thinking of running the whole scenario for the
examples step table rather than just the step.
On Tue, Apr 21, 2009 at 10:20 PM, Joseph W. [email protected]
wrote:
we embedded a Examples table in the step.
I think it would be conceptually easier for a non-technical user to
grasp than my first suggestion which makes it a big win for me.
Thanks a lot for all the suggestions so far. I like Ben’s subtable too.
In the example: “I should be presented a menu with ” I
assume
the step definition would be:
Then /I should be presented a menu with/ do |meat_hash|
meat_hash has the following value the 2nd time (Jewish):
{‘Pork’=>‘N’, ‘Lamb’=>‘Y’, ‘Veal’=>‘Y’}
end
However, having the as part of the step would be
inconsistent
with how the regexp matching is currently working.
The idea is that we add a new kind of multiline argument in addition to
pystrings and tables: Hash. This is
done using the familiar <> delimiters as a multiline argument. What’s
inside
it has no significance other than documentation.
The keys of the hash would be the same as the Examples table header minus
the columns that are referred in other steps.
In essence it achieves the same as Ben’s, but relying on a convention
(removing referenced columns) rather than introducing
a new, more complex table markup.
>> What you really want is an examples table that is embedded in a
Not quite, I was thinking of running the whole scenario for the
In the example: “I should be presented a menu with ” I
Here is an alternative: Multiline Example Hash · GitHub
a new, more complex table markup.
WDYT?
Interesting… so your meat_hash was derived from the columns of the
table that were not used previously in the scenario? Meaning, that is
why Religion was not part of your meat_hash.
That makes sense, and… since the scenario outline is parsed before any
of the examples are ran through that convention could be maintained no
matter what order the delimiters appear in the scenario. (Just thinking
out loud here…)
Yeah, I like it. I also agree with Matt about meat_hash. All this
meat_hash talk is making me hungry…
However, what if people wanted multiple hashes? Subtables would allow
for this but a single hash solution would not. FWIW, here is a very
contrived exampled:
I agree that the sub-table is probably adding too much complexity,
especially since we have a simpler alternative and no real use cases for
it yet. Basically, you can ignore that last gist, I was just
experimenting with contrived use cases.
I would prefer it to be explicit what columns I am using, that way if
you
have two steps that require this technique in your scenario it still
works.Relying
on an implicit ‘the rest’ doesn’t work in that situation.
In my scenario I would like to have something like this…
Given I am logged in as
And I have a Protocol
When I clone the protocol
Then the new protocol will contain
Examples:
*| Role | Initial Protocol Details ||| Cloned Protocol Details
|||
*| | Name | Urgent | Description | Name | Urgent | Description
|
| Admin| Prot1 | Y | Protocol 1 | Prot~1 | Y | Clone of
Protocol 1 |
| Admin| Prot1 | N | Protocol 1 | Prot~1 | N | Clone of
Protocol 1 |
etc.
Here I am using ||| to signify the number of columns that are included
in
the above grouping. Not sure how best to indicate which rows are header
rows.
no offense to anyone here but all this is starting to remind me of
the days of green ASCII terminals… there’s a reason gui’s, wysiwyg
editors and typographic fonts were invented…
ok, nevermind, back to plain text, proportional font, character chart
art …
On Tue, Apr 21, 2009 at 11:39 AM, aslak hellesoy [email protected] wrote:
Being the author of Cucumber, some of you might be surprised that I ask this
question:
How should I go about to implement a Cucumber feature and step definition
with the following data? 1) Religious Menu · GitHub (just look at the first file for now)
You left out:
| Vegetarian | N | N | N |
like to express this sort of problem?
How about something like this:
That doesn’t require a new construct and I think it solves the
problem (obviously I haven’t run it).
An alternative would be to add a new rule or construct in which the
step definition can drive things a bit more. Something like step_defs.rb · GitHub where the fact that the step def accepts
3 block args would let it consume the next three columns in the table.
Not sure how crazy that would be - just an idea.
In Cucumber, there are several ways to put this table in a feature. It
up with. The Scenario Outline version has annoying duplication. I have to
how. Is there a smarter way with the current Cucumber? If not, how would
you like to express this sort of problem?
This is actually one of the best I’ve seen so far. However it doesn’t
scale
for multiple columns. (Imagine if you have 5 of them - they easily get
mixed
up, or you make a spelling mistake).
I have also taken the meat+hamburge example and tweaked a little bit:
As you can see I’m a little sceptical of complex tables. Instead I have
invented the Range for feature writers. You specify a range of columns
you
want for a column hash. (This could work along with my example where you
don’t specify a range, just any token, and get the “rest”).
That doesn’t require a new construct and I think it solves the
problem (obviously I haven’t run it).
An alternative would be to add a new rule or construct in which the
step definition can drive things a bit more. Something like step_defs.rb · GitHub where the fact that the step def accepts
3 block args would let it consume the next three columns in the table.
Not sure how crazy that would be - just an idea.
That’s an interesting idea, but would’t this introduce a positional
dependency that could make it hard to detect mistakes? I’ll have to
think
more about it.
On Wed, Apr 22, 2009 at 2:27 AM, Jonathan L. [email protected]wrote:
no offense to anyone here but all this is starting to remind me of the days
of green ASCII terminals… there’s a reason gui’s, wysiwyg editors and
typographic fonts were invented…ok, nevermind, back to plain text,
proportional font, character chart art …
Text is king. It’s always possible to build GUIs on top of text. And
that
will happen with Cucumber. One of FIT’s biggest flaw (IMO) is that it
doesn’t have an underlying format below HTML (too high level).
Ok - let’s not derail the table discussion in this thread.
My initial approach to this (when I hit it in my work) was to get around
this problem by catching the whole row from the example in the
Before(scenario) filter, putting it into a well known member @data, so
all
steps have access to it.
The problem with this is that it is then implicit which fields are used
by
each step, not explicit. This leaves me feeling sad as it looses some of
it’s power as documentation.
It also means you can’t use the same step from an outline in a normal
scenario. (but I don’t see a way around this with any of the solutions…
except “given … ”)
