[rspec-users] How to spec error_messages_for
work at ashleymoran.me.uk
Wed Mar 21 16:30:52 EDT 2007
On Mar 21, 2007, at 5:12 pm, David Chelimsky wrote:
> "Danger, danger, Will Robinson!"
> The fact that you have to ask this question is a sign that you
> probably shouldn't be doing this. The answer lies in AR internals,
> which is stuff you really shouldn't be mocking.
When I gave up reading through the Rails API and code I had started
to come to that conclusion already. Unfortunately I've redefined
error_messages_for to give more control over the output (why it takes
so few parameters, I don't know). Now, I can spec my new helper
method easily enough, but that doesn't help if I can't test if it
gets called. It's one thing testing the output of a currency
formatter, it's another thing to have to copy and paste tests for
multi-line HTML every time it's used.
> Imagine that you do this, and a new version of rails implements this
> differently. You may start getting a bunch of failing integration
> tests w/o failing isolation tests and they'll be very difficult to
> track down.
Which makes me wonder... why is it so hidden? I know it's nice to
have some Ruby magic so I can call helper methods like "<%= my_method
('blah') %>" in the view source, but really, I'd be just as happy
writing "<%= page.my_method('blah') %>" if it made it more transparent
The only solution I can think of is to find whatever trainwreck takes
me from @controller to the thing with error_messages_for, and write
an assumption spec for its current implementation, so that if and
when that changes, I'm notified of it. The only alternative I can
see is lengthy, redundant should-have_tag specs. What do you think
of this as a compromise?
More information about the rspec-users