[rspec-users] Rspec

David Chelimsky dchelimsky at gmail.com
Mon Jun 28 16:32:54 EDT 2010


On Jun 28, 2010, at 3:03 PM, Curtis j Schofield wrote:
> On Mon, Jun 28, 2010 at 11:50 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Jun 28, 2010, at 1:31 PM, Curtis j Schofield wrote:
>> 
>>> Hi - I extracted some methods in a refactor and put them into a nice
>>> module and i'm in the process of making sure it is covered as a
>>> first-class unit.
>>> 
>>> I'm getting some strange behavior with what seems really straight forward code.
>>> 
>>> https://gist.github.com/6d54448d70b07a126c51
>> 
>> should_receive replaces the method in question, so when you say:
>> 
>>  @foo.should_receive(:toad_string)
>> 
>> the actual toad_string method is never invoked, hence control is not passed on to toad_nokogiri_xml_document.
>> 
>> In general, mocking and stubbing methods on the object your testing should be avoided, for exactly this reason.

> Any suggestions for how to detect that the methods are getting executed that need to get executed?

In general, I'd recommend avoiding this sort of binding to internal implementation. This is not the same thing as specifying that an object plays correctly with another object, in which case mocking methods on the _other_ object is a common practice. In this case, however, you have a single object that has an API and produces different results depending on what you send to it. So I'd specify that.

If you really feel that you need to specify the internal delegation, then do it one method at a time:

describe Foo do
  describe "a" do
    it "delegates to b" do
      foo = Foo.new
      foo.should_receive(:b)
      foo.a
    end
  end

  describe "b" do
    it "delegates to c" do
      foo = Foo.new
      foo.should_receive(:c)
      foo.b
    end
  end
end

class Foo
def a
  b
end
def b
  c
end
def c
  "end of the line"
end
end

HTH,
David

PS - I moved your post from the top. Please post in line or at the bottom so readers can follow the thread.




More information about the rspec-users mailing list