[rspec-users] How to spec error_messages_for

David Chelimsky dchelimsky at gmail.com
Thu Mar 22 13:52:32 EDT 2007

On 3/21/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
> 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).

This is an interesting case because the behaviour you want to describe
is no longer in your app - it's actually new behaviour in Rails itself
(in your patch of rails).

What I prefer to do in this case is patch the rails tests as well,
rather than adding tests to my app(s). I keep a set of patches around
that patch both tests and implementation and whenever I install rails
in a project, I run these patches and don't worry about it in the
examples for my app.


> 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

Rails is all about opacity. I re-learn that lesson nearly every day.

> 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?

Well, it doesn't make me want to jump for joy, but I might choose to
do it this way anyhow. Lesser of many evils and all.


> Ashley
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list