[rspec-devel] If you set an expectation on something that's already stubbed, should it return the stubbed value?

Pat Maddox pergesu at gmail.com
Sun Sep 14 23:33:32 EDT 2008


Sorry about that...I really am trying to become a better writer. I'll
keep working at it.

Anyway, cool, it sounds like I can merge it in to trunk soon.

Pat



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


More information about the rspec-devel mailing list