On Wed, Feb 25, 2009 at 10:39 AM, Jeff Talbot <jeff.a.tal...@gmail.com> wrote: > > > On Wed, Feb 25, 2009 at 10:23 AM, David Chelimsky <dchelim...@gmail.com> > wrote: >> >> On Wed, Feb 25, 2009 at 10:10 AM, Jeff Talbot <jeff.a.tal...@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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
