On Tue, Jan 6, 2009 at 12:16 PM, Stephen Eley <[email protected]> wrote: > On Tue, Jan 6, 2009 at 10:53 AM, Matt Darby <[email protected]> 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 ([email protected]) > ESCAPE POD - The Science Fiction Podcast Magazine > http://www.escapepod.org > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
