[rspec-users] Method stub return values for message expectations

David Chelimsky dchelimsky at gmail.com
Sun Jun 13 16:20:48 EDT 2010


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


More information about the rspec-users mailing list