<div dir="ltr">Took me a couple of reads to understand this aswell - but I'm very much in favour of it. <br><br><div class="gmail_quote">On Mon, Sep 15, 2008 at 2:34 PM, Zach Dennis <span dir="ltr"><<a href="mailto:zach.dennis@gmail.com">zach.dennis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="Wj3C7c">On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <<a href="mailto:pergesu@gmail.com">pergesu@gmail.com</a>> wrote:<br>
> I'm pretty set on this (though I'll hold off on making changes<br>
> until I feel all opinions are given thorough discussion). But there's<br>
> one case where it's not 100% clear to me what to do were we to make<br>
> these changes.<br>
><br>
> Here's an example I wrote in my previous email:<br>
> it "should render a 404 when the book is not found" do<br>
> Book.should_receive(:find).with("1").and_return nil<br>
> get :show, :id => "1"<br>
> response.code.should == "404"<br>
> end<br>
><br>
> Now, I actually wouldn't write that example. I'd write it as:<br>
> it "should render a 404 when the book is not found" do<br>
> Book.stub!(:find).and_return nil<br>
> get :show, :id => "1"<br>
> response.code.should == "404"<br>
> end<br>
><br>
> There's no reason to set an expectation there, the best way to express<br>
> the intent of that example is to stub it and return nil, indicating<br>
> that we expect different behavior when it's nil. Anyway, I used<br>
> should_receive in the previous email in case anyone picked up on this<br>
> and discussed that instead instead of the intent of the email.<br>
><br>
> So this begs the question, in my mind, what happens when you do:<br>
> it "should render a 404 when the book is not found" do<br>
> Book.stub!(:find)<br>
> get :show, :id => "1"<br>
> response.code.should == "404"<br>
> end<br>
><br>
> My inclination is that it would work the same as the expectation - it<br>
> would just return the same value as was originally stubbed. The<br>
> difference is that doing this stub would effectively be a noop. Now I<br>
> CAN see the point that you're re-stubbing this method and it would<br>
> maybe clear out any existing stubs...but again I think it's a bad idea<br>
> to rely on the reader's knowledge that stub!, by default, returns nil.<br>
> Then again, it is a tad weird that stub! would set it up to return nil<br>
> in one context, but some different value in another context.<br>
><br>
> Over all, I think consistency with the expectation API, as well as<br>
> encouraging developers to express intent better in their examples,<br>
> wins out.<br>
><br>
<br>
</div></div>I'm pretty sure I misread your first email thinking that you wanted to<br>
replace the usage of and_return with reliance on the stubbed out<br>
values from the befores, which I gave a -1 to since I felt that would<br>
provide confusion and lack of clarity. But I don't think that is at<br>
all what you were suggesting.<br>
<br>
To communicate back to you what I think you're suggesting... you'd<br>
like to remove unnecessary usages of and_return when it isn't used to<br>
exemplify the intent of an example. And your argument for principle of<br>
least surprise I do agree with. Not that it matters, but +1.<br>
<br>
Thanks for taking the time to share what you're thinking more than once. ;)<br>
<div class="Ih2E3d"><br>
<br>
--<br>
Zach Dennis<br>
<a href="http://www.continuousthinking.com" target="_blank">http://www.continuousthinking.com</a><br>
<a href="http://www.mutuallyhuman.com" target="_blank">http://www.mutuallyhuman.com</a><br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">rspec-devel mailing list<br>
<a href="mailto:rspec-devel@rubyforge.org">rspec-devel@rubyforge.org</a><br>
<a href="http://rubyforge.org/mailman/listinfo/rspec-devel" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-devel</a><br>
</div></div></blockquote></div><br></div>