[rspec-users] Help with controller spec?
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
> that out by making the request and checking the response, but if you
> 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.
> 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
> Have Fun,
> Steve Eley (sfeley at gmail.com)
> ESCAPE POD - The Science Fiction Podcast Magazine
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users