Here is the same thing as a gist http://gist.github.com/99443 2009/4/22 Nigel Thorne <rs...@nigelthorne.com>
> 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 <Role> > And I have a Protocol <Initial Protocol Details> > When I clone the protocol > Then the new protocol will contain <Cloned Protocol Details> > > > 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. > > WDYT? > > > 2009/4/22 Ben Mabey <b...@benmabey.com> > > 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 >> > >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
