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".
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090225/771953f7/attachment.html>
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. FWIW, I''d avoid mixing stub! and should_receive for cases like this, just to avoid the sort of confusion you''re experiencing. Cheers, David> > Jeff > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
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? Jeff> Cheers, > David > > > > > Jeff > > > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090225/c3fe63d3/attachment.html>
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