[rspec-users] Surprised by stub/mock interaction

David Chelimsky dchelimsky at gmail.com
Wed Feb 25 12:51:45 EST 2009


On Wed, Feb 25, 2009 at 10:39 AM, Jeff Talbot <jeff.a.talbot at gmail.com> wrote:
>
>
> On Wed, Feb 25, 2009 at 10:23 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>>
>> On Wed, Feb 25, 2009 at 10:10 AM, Jeff Talbot <jeff.a.talbot at gmail.com>
>> wrote:
>> > Hello,
>> >
>> > Something I do often is use stub methods in before blocks and mock
>> > expectations in a specific examples (much like described here:
>> >
>> > http://blog.davidchelimsky.net/2006/11/9/tutorial-rspec-stubs-and-mocks).
>> >
>> > I was just surprised with an instance of doing this and I thought I'd
>> > check
>> > with the group to see if I shouldn't have been.
>> >
>> > What should be the expected output of the following -- assume it's the
>> > only
>> > code in a spec file:
>> >
>> >   class Foo; def bar; end; end
>> >
>> >   it "should print something" do
>> >     foo = Foo.new
>> >     foo.stub!(:bar).and_return(true)
>> >     foo.should_receive(:bar).at_least(:once).and_return(false)
>> >     puts foo.bar
>> >     puts foo.bar
>> >   end
>> >
>> > I expected "false / false". The actual output is "false / true".
>>
>> "false / true" is correct.
>>
>> The first call to foo.bar satisfies the message expectation
>> (should_receive), so the message expectation is no longer paying
>> attention after that. If there was no stub, it would field any
>> subsequent calls, but in this case the stub gets it.
>
> Makes sense, and after thinking about it some more I think I'm fully
> satisfied with that explanation.
>
>>
>> FWIW, I'd avoid mixing stub! and should_receive for cases like this,
>> just to avoid the sort of confusion you're experiencing.
>
> By "cases like this" I assume you mean cases where the method is invoke
> multiple times?

Yep. I'd avoid the stub in this case.

>
> Jeff
>
>>
>> Cheers,
>> David
>>
>> >
>> > Jeff


More information about the rspec-users mailing list