| Jewish | Lamb, Veal |
| Muslim | Lamb, Veal |
| Hindu | Lamb |
This certainly would work, but what if we’re not dealing with booleans
(Lamb/No Lamb), but numbers?
|34,76,89| doesn’t read so well…
Actually, I did just that, together with a colleague.
(I removed info about what the algorithm actually computes, but
the +/- indicates a threshold for that algorithm is/is not crossed;
there are four algorithms not two; sorry about all that editing)
Scenario Outline: measuring a series of daily weights
Given patient Lara
When she measures her weight as kg
Then ROT algorithm result should be
And MACD algorithm result should be
…
Examples:
| weights | ROT | MACD | ...
| 71 72.5 72 73.3 73.6 | + | - |
| 71 72 73 74 75 | - | + |
...
I find this readable enough (it is much more readable than the long
series of scenarios we had before).
The numbers are a sequence as input for the algorithm.
The sequences are concrete examples to show the differences between the
outcomes of the four algorithms.
What strikes me in your meat examples, is that there is a mapping
from religion to types of meat that can be served (or dishes, in the
end).
You can test that the mapping works, why are you trying to be
exhaustive in your examples?
Bye,
Kero.
From: aslak hellesoy [email protected]
Here is an alternative: Multiline Example Hash · GitHub
I’m a fan of simple, which means I’m a fan of this. The only thing I
can think of that would be simpler is this:
-
When the arity of the matcher is larger by one than the matched step
provides, pass the hash from the current scenario in that slot (barf if
there’s no table or scenario-table to fill that arg).
-
Also, don’t remove any values from the hash based on
already-used-ness (no important reason to have it, leaves things more
flexible for the developer, and is also simpler. Win!).
I see one downside here: the implicitness. That could be solved by one
of:
-
The extra line from the gist above. With the implicitness it
has, it feels like a wash to me. I’ve added something that introduces
extra questions instead of just being understood.
-
Convention, or even formal syntax like “… from the scenario” (i.e.,
if you’re implicitly expecting the scenario row to go into the matcher,
say so in the G/W/T line).
-
You could have a ‘strict’ or ‘warnings’ setting (hi, I coded in Perl
for 15 years) or the opposite, a “I’ve done what I intended, just run
'em” setting, to help ensure the user gets what she wants (with respect
to the arity mismatch).
I think it’s clear, I lean toward the convention of saying “… from the
scenario table” or something example-specific: “The menu should have the
correct meat offerings”. I don’t think the ‘strict’ mode is needed.
Nobody’s going to question that the step definition will have the
necessary information available to it - they might question how it gets
there (Cuke internal implementation) or how they get at it (adding the
extra arg to the |arg,list,hash|). But I think it’s sufficiently
intuitive when all things are considered.
If you like this, please send the two cents to… oh, never mind 
Randy