My initial approach to this (when I hit it in my work) was to get around this problem by catching the whole row from the example in the Before(scenario) filter, putting it into a well known member @data, so all steps have access to it. The problem with this is that it is then implicit which fields are used by each step, not explicit. This leaves me feeling sad as it looses some of it's power as documentation.
It also means you can't use the same step from an outline in a normal scenario. (but I don't see a way around this with any of the solutions.. except "given ... <Pork> <Lamb> <Beef>") Nigel 2009/4/23 <r_j_h_box...@yahoo.com> > > > ------------------------------ > *From:* aslak hellesoy <aslak.helle...@gmail.com>* > * > > Here is an alternative: http://gist.github.com/99376 > > 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 <meats> 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 > > > > > > > > > _______________________________________________ > 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
