Aslak Hellesøy wrote:
>
> If you don't do this, the multiline argument is "dangling". Steps that
> take multiline arguments should be formulated in such a way that
> removing the multiline argument makes the sentence nonsensical.
Yes, I understood that. And I also realized that the solution is to
have two separately phrased matcher clauses. However, this approach
does strike me as incongruous with cucumber's philosophy of reading
naturally.
Consider this situation.
Iteration 1 to 5
Then we should have currency exchange rates for "USD" on file
Iteration 6
Then we should have currency exchange rates for "USD" on file with the
following codes
| code|
|"EUR"|
|"JPY"|
Now, besides begin awkwardly worded, "rates for "USD" on file with the
following codes" (which admittedly could be repaired with some thought),
this requires that an additional matcher be provided in the step
definition file. Further, the similarity of phrasing is an invitation
to a matcher collision. I rather suspect that in these cases this is
what will end up in the feature files on most occasions:
Then we should have currency exchange rates for "USD" on file
Then we should have currency exchange rates for "EUR" on file
Then we should have currency exchange rates for "JPY" on file
This requires far less work as the matcher already exists and one need
only replace six characters after a couple of cut and pastes.
Presently, the table method works best, I think, when it is employed
from the outset. However, when things are elaborated after the initial
matchers are written then it seems more work than it is worth to
duplicate existing matchers just to cut down somewhat on boilerplate in
the feature files.
If, instead, one could just add a table under an existing step matcher
then this would be more in keeping with what cucumber does so well
elsewhere, extend features and scenarios naturally and effortlessly.
Then we should have currency exchange rates for "USD" on file
| code|
|"EUR"|
|"JPY"|
This is more user friendly because it creates far less of an
intellectual load (having to devise a new wording for an existing phrase
and implementing same as a special case) than simply extending the
existing structure.
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
