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
