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
On 10/30/08, Lenny Marks <[EMAIL PROTECTED]> 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
> [email protected]
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
