[rspec-users] Help with controller spec?

David Chelimsky dchelimsky at gmail.com
Tue Jan 6 13:24:02 EST 2009


On Tue, Jan 6, 2009 at 12:16 PM, Stephen Eley <sfeley at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 10:53 AM, Matt Darby <matt at matt-darby.com> wrote:
>> I'm stumped. How would I go about specing the "update_sandbox" method?
>
> I couldn't hope to compete with David's answer when it comes to
> specifics, but more generally, it occurs to me that your question is a
> little imprecise and that could point to part of the cognitive
> disconnect.  You ask how to spec the method, but you're NOT specing
> the "update_sandbox" method in the example you posted.  You're specing
> a controller's "new" action.  Creating a stub or mock for a method
> isn't the same as specing it.  A spec tests something to see if it
> does what it's supposed to.  Mocking or stubbing is the opposite:
> instead of testing the method, you're pretending the method doesn't
> exist and replacing it with a cardboard cutout.
>
> Other things I noticed:
>
> 1.) There's really no point in putting identical stub!() and
> should_receive() declarations in the same example.  should_receive()
> does everything stub!() does and slightly more.  It replaces the
> method AND says "Complain if this doesn't get called."  When you see
> them used in the same spec file, what you're usually seeing is stub!()
> in the "before" blocks just to replace external interfaces and make
> sure nothing breaks, and then should_receive() in multiple individual
> examples to prove that things called when they should.
>
> 2.) On that note, it's becoming more and more the accepted practice to
> have only one "should" per example.  (Including "should_receives" or
> other mocks.)  That way, if one of the expectations breaks, you'll
> know which one from the "it should..." text and won't have to look at
> individual lines.
>
> 3.) You _could_ probably make this spec work as it stands by changing
> the "update_sandbox" call to expect a Proc with the "render_to_string
> ..." block included; that's what actually happens when you call a
> method with a "do" block, you're passing it an anonymous Proc as a
> parameter.  Tweak it enough and I'll bet you could get this to work.
>
> 4.) BUT, I agree with David, there's probably no point.  At this level
> your spec becomes sort of trivial; you're not even testing behavior
> any more, you're testing for the existence of certain lines of code.
> Think big picture: WHY are you testing?  What is it you want to prove?
>  Your users don't care whether render_to_string() ever gets called
> with certain parameters, and tomorrow you won't care either.  You DO
> care whether the controller's "new" method responds with an
> appropriate block of Javascript when accessed via AJAX.  You can find
> that out by making the request and checking the response, but if you
> stub out the part that actually generates the Javascript, all you'll
> learn is "the controller get called and it responded."  If that's all
> you want to know, you could mock update_sandbox to return "neener
> neener" and test for THAT.  (And make sure to spec the
> update_sandbox() method thoroughly elsewhere.)
>
> 5.) OR...  You might gain some good food for thought by going to the
> MerbCamp videos (http://merbcamp.com/video) and watching Yehuda Katz's
> video on testing (http://merbcamp.com/video/katz1.mp4).  Don't worry
> about the Merb stuff; what he's describing is a general approach and
> it's just as applicable to Rails.  The philosophy is somewhat contrary
> to the "unit test everything in isolation" philosophy that many others
> espouse, but it doesn't hurt to learn both and decide which style
> suits you best.

I'd refine that a bit: learn both and decide *when to apply each*.

Choosing one style over the other limits your toolbox and consequently
your ability to operate in different contexts.

FWiW,
David

>
> I personally found Yehuda's approach to be a slap of cold water and
> then a breath of fresh air; since I started it, I've almost entirely
> stopped mocking things, and I no longer have the frustrating feeling
> that I'm spending 10x longer on tests (and testing my tests, and
> debugging my tests) than I am on my application features.  But again:
> think for yourself, and decide what suits your goals and learning
> path.
>
>
> --
> Have Fun,
>   Steve Eley (sfeley at gmail.com)
>   ESCAPE POD - The Science Fiction Podcast Magazine
>   http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list