[rspec-users] stub followed by should_receive behavior changed

Pat Maddox pergesu at gmail.com
Thu Oct 30 17:29:27 EDT 2008

You're right, the behavior did change. Now when you have a
should_receive that shadows a previous stub, it returns or yields the
original value.

I don't know a way to turn off the yielding in the should_receive,
I'll look at putting something in. In the mean time, if you stub the
method again with no yield value, and then expect it, it ought to work


On 10/30/08, Lenny Marks <lenny at aps.org> wrote:
> I'm in the process of trying to get updated to rspec-1.1.11(from
> 1.1.1). I have a couple of places where I was trying to verify that a
> particular collaboration was made inside a transaction. My general
> strategy was to start off using something like Transaction.stub!
> (:execute).and_yield in a before block. Then in the specs to verify
> execution within a transaction I would override the stub with
> Transaction.should_receive(:execute), no and_yield, and check the
> collaborations did not occur. Unfortunately this doesn't work anymore
> and I'm not sure if that was intentional or not.  The following
> example passes in 1.1.1 but not in 1.1.11. Also open to better
> approaches.
> Thanks,
> -lenny
> class Klass
>     def transaction
>        raise "error from implementation"
>        yield
>     end
> end
> describe "when using a stub with and_yield" do
>     before do
>        @klass = Klass.new
>        @klass.stub!(:transaction).and_yield
>     end
>     it "should yield without explicit expectation" do
>        Proc.new do
>           @klass.transaction { raise "error from yield" }
>        end.should raise_error("error from yield")
>     end
>     it "should not yield with explicit expectation without and_yield" do
>        @klass.should_receive(:transaction)
>        @klass.transaction { raise "error from yield" }
>     end
> end
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list