[rspec-users] How to spec error_messages_for

[Ashley Moran]

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.

David,

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?

Ashley