[rspec-users] [Cucumber] Tables

Ben Mabey ben at benmabey.com
Tue Apr 21 18:20:23 EDT 2009

aslak hellesoy wrote:
> On Tue, Apr 21, 2009 at 10:20 PM, Joseph Wilk <joe at josephwilk.net 
> <mailto:joe at josephwilk.net>> wrote:
>     On Tue, Apr 21, 2009 at 7:32 PM, Jonathan Linowes
>     <jonathan at parkerhill.com <mailto:jonathan at 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.

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. :)


> Aslak
>     --
>     Joseph Wilk
>     http://blog.josephwilk.net
>     >
>     https://rspec.lighthouseapp.com/projects/16211/tickets/149-step-outline
>     >
>     > _______________________________________________
>     > rspec-users mailing list
>     > rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org>
>     > http://rubyforge.org/mailman/listinfo/rspec-users
>     >
>     _______________________________________________
>     rspec-users mailing list
>     rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/rspec-users
> ------------------------------------------------------------------------
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list