Forum: RSpec stub followed by should_receive behavior changed

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Lenny M. (Guest)
on 2008-10-30 22:37
(Received via mailing list)
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


class Klass
    def transaction
       raise "error from implementation"

describe "when using a stub with and_yield" do

    before do
       @klass =

    it "should yield without explicit expectation" do do
          @klass.transaction { raise "error from yield" }
       end.should raise_error("error from yield")

    it "should not yield with explicit expectation without and_yield" do


       @klass.transaction { raise "error from yield" }

Pat M. (Guest)
on 2008-10-30 23:31
(Received via mailing list)
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

This topic is locked and can not be replied to.