rspec users - Jun 2010 - Rspec

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

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.

HTH,
David

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


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.
>
> HTH,
> David
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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.