Stub followed by should_receive behavior changed


#1

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


#2

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

Pat