________________________________
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