aslak hellesoy wrote:
On Tue, Apr 21, 2009 at 10:20 PM, Joseph Wilk <j...@josephwilk.net
<mailto:j...@josephwilk.net>> wrote:
On Tue, Apr 21, 2009 at 7:32 PM, Jonathan Linowes
<jonat...@parkerhill.com <mailto:jonat...@parkerhill.com>> wrote:
>
> On Apr 21, 2009, at 1:57 PM, Joseph Wilk 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.
However I really like Ben's suggestion of a sub-table
(http://gist.github.com/99255).
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 <Meat Options>" 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 <Meat Options> as part of the step would be
inconsistent with how the regexp matching is currently working.
Here is an alternative: http://gist.github.com/99376
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.
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:
http://gist.github.com/99424
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. :)
-Ben
Aslak
--
Joseph Wilk
http://blog.josephwilk.net
>
https://rspec.lighthouseapp.com/projects/16211/tickets/149-step-outline
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org>
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org>
http://rubyforge.org/mailman/listinfo/rspec-users
------------------------------------------------------------------------
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
