rspec users - Jun 2010 - Method stub return values for message expectations

Hi,

RSpec has long had the ability to set a message expectation for a stubbed method
without disrupting its (stubbed) return value. This is really helpful for a
variety of reasons, not least because it decouples the stubbed method''s
return value from the expectation that the method will be called, which for
example is often necessary when an expectation appears in a shared example group
and the corresponding return value is stubbed differently by the different
contexts which use that shared group.

This still works fine as long as no argument matchers are involved:
> > A.stub!(:msg).and_return(:special_value)
> > A.should_receive(:msg)
> > A.msg
> => :special_value
But as of http://github.com/dchelimsky/rspec/commit/386e334 (i.e. in 1.3.0) it
no longer works when the stub uses an argument matcher:
> > A.stub!(:msg).with(:arg).and_return(:special_value)
> > A.should_receive(:msg).with(:arg)
> > A.msg(:arg)
> => nil
This is a pain because I always prefer to lock down stubbed methods with
argument matchers where possible; while the message expectations verify that a
particular set of method calls are necessary, their corresponding stubs + arg
matchers verify that the same set of calls is sufficient, i.e. there
aren''t any other calls to stubbed methods (with unexpected arguments)
that you don''t know about.

So, has something been broken? Or is using argument matchers with stubs
unsupported in the first place?

Cheers,
-Tom

On Jun 13, 2010, at 4:15 PM, Tom Stuart wrote:
> Hi,
> 
> RSpec has long had the ability to set a message expectation for a stubbed
method without disrupting its (stubbed) return value. This is really helpful for
a variety of reasons, not least because it decouples the stubbed
method''s return value from the expectation that the method will be
called, which for example is often necessary when an expectation appears in a
shared example group and the corresponding return value is stubbed differently
by the different contexts which use that shared group.
> 
> This still works fine as long as no argument matchers are involved:
> 
>>> A.stub!(:msg).and_return(:special_value)
>>> A.should_receive(:msg)
>>> A.msg
>> => :special_value
> 
> But as of http://github.com/dchelimsky/rspec/commit/386e334 (i.e. in 1.3.0)
it no longer works when the stub uses an argument matcher:
> 
>>> A.stub!(:msg).with(:arg).and_return(:special_value)
>>> A.should_receive(:msg).with(:arg)
>>> A.msg(:arg)
>> => nil
> 
> This is a pain because I always prefer to lock down stubbed methods with
argument matchers where possible; while the message expectations verify that a
particular set of method calls are necessary, their corresponding stubs + arg
matchers verify that the same set of calls is sufficient, i.e. there
aren''t any other calls to stubbed methods (with unexpected arguments)
that you don''t know about.
> 
> So, has something been broken? Or is using argument matchers with stubs
unsupported in the first place?
That commit was just a refactoring - no intent to change behavior - just missing
an example for this particular case. Please report to
http://rspec.lighthouseapp.com for rspec-1 and
http://github.com/rspec/rspec-mocks for rspec-2 (the two separate places to
report bugs is a temporary situation).

Thx,
David

On 13 Jun 2010, at 21:20, David Chelimsky wrote:
>> But as of http://github.com/dchelimsky/rspec/commit/386e334 (i.e. in
1.3.0) it no longer works when the stub uses an argument matcher:
> Please report to http://rspec.lighthouseapp.com for rspec-1 and
http://github.com/rspec/rspec-mocks for rspec-2
Done: https://rspec.lighthouseapp.com/projects/5645/tickets/1009,
http://github.com/rspec/rspec-mocks/issues#issue/5.

Cheers,
-Tom