On Nov 1, 2011, at 12:59 PM, David Hofer wrote:
> I recently saw a test passing when it should have failed, because the
> person who wrote it used should_not_receive instead of
> should_receive. Here is a simple example illustrating the behavior:
>
> class MyTest
> def foo
> puts "hey"
> end
>
> def bar
> foo
> end
> end
>
> describe MyTest do
> it "passes but should fail" do
> subject.should_not_receive(:foo).once
> subject.bar
> end
> end
>
> If I remove the ".once" the test fails, as I would expect.
>
> Is this intended behavior? It seems really weird to me.
>
> I am seeing this with rspec 1.3.2 and rspec-rails 1.3.4.
It is really weird, but it's also a misunderstanding of the API.
should_receive(:foo) defaults to an expectation of 1 time. The object then
exposes methods like once, twice, exactly(3).times to specify/modify the
expectation:
foo.should_receive(:bar).once
foo.should_receive(:bar).twice
foo.should_receive(:bar).exactly(3).times
Yes, I was sorely tempted to support
foo.should_receive(:bar).three_times_a_lady when we added all that, but I
refrained. Now that Siri will reenact the entire "Who's on first?" routine, I'm
reconsidering.
That aside, to specify that a message would not be received, we used to have to
write:
foo.should_receive(:bar).exactly(0).times
We later added foo.should_not_receive(:bar) as a shorter, more expressive
version of that.
So, since methods like once, twice, exactly(n).times, at_least(n).times and
at_most(n).times all modify the constraint, it turns out that they could be
used together, like this:
foo.should_receive(:bar).once.twice.exactly(3).times
In this case, it would expect :bar 3 times, because the last modification wins.
Of course you would never do that deliberately, and in my 5 1/2 years running
this project this is the first time I've ever seen any issue w/ this, but that
is actually not prevented. Therefore, the following are equivalent:
foo.should_receive(:bar).exactly(0).times.once
foo.should_not_receive(:bar).once
Hope that helps you to understand the problem. In terms of what we can/will do
about it, I don't really think we'll do anything about it but document it
better. It would require too much work to solve this without breaking other
things, and it turns out that mocha, flexmock, and RR all have the same issue:
foo.expects(:bar).never.once
flexmock(foo).should_receive(:bar).never.once
mock(foo).bar.never.once
Cheers,
David
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
