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 _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
