On Jun 28, 2010, at 3:03 PM, Curtis j Schofield wrote:
> On Mon, Jun 28, 2010 at 11:50 AM, David Chelimsky <dchelim...@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.
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
