Ok, well it seems that the answer to my direct question is that no, there's
no way to test message expectations without an explicit receiver; thanks for
the responses.
I suppose I should respond to the comments re: more general issue of testing
strategy [hopefully this doesn't ignite too long of a thread]:
I completely agree that the goal should be to disconnect testing from
implementation as much as possible. In general, this requires finding the
simples set of N inputs to a method that cover all the basic behavior you
want to test for, and making sure that the appropriate output is generated
for all of those cases.
This may work for the majority of methods you encounter; but it's not always
practical. Sometimes a method is complex enough that the N inputs you would
need to describe all behavior can be too large to be practical. We want to
test thoroughly and to test in a way that's easy to maintain. Overall it is
easier to maintain tests that don't rely at all on implementation, but it is
also easier to maintain a smaller number of tests than a very large number
of tests. These two things have to be balanced.
So, I do agree with the general rule, but it doesn't apply in every
situation. And, to be clear, this has nothing to do with testing protected
methods, which of course shouldn't be done. Here's an example to illustrate
my point:
Suppose methodA does the following:
* parse a data file uploaded by the user
* reformat the parsed data to deal with a variety of different allowable
configurations
* perform calculations on the collected data
In the implementation, I might refactor the functionality into three smaller
methods (one for each bullet), and just call those three smaller methods
from within methodA. Those other methods will also be public (they might
need to be called from elsewhere), and I test each of them separately. So,
having tested all of the functionality described by those three bullets
separately, all I really care about in testing methodA is that it is
actually calling those three methods. Otherwise, re-testing all that
functionality is not at all DRY.
Even if I wanted to re-test all of the functionality, it can be next to
impossible. Suppose I write 20 tests to fully spec out each of the three
methods called from within methodA (because there are 20 distinct sets of
behaviors that describe all the possible behaviors of each of those
methods). In this case, if I wanted to test methodA without referencing any
internal logic at all, I might be required to write 20^3 = 8,000 tests to
fully cover all of the logic described by the 60 tests used to cover the
three subroutines.
On Fri, Apr 10, 2009 at 4:42 PM, Nigel Thorne <rs...@nigelthorne.com> wrote:
> Hi Barun,
> Here is my take on this...
>
> Why are you mocking methods on the object under test? The aim of BDD is to
> specify the behaviour of the class. When you are mocking, the intention is
> to spec one object in isolation. When you define expectations between
> objects you are specifying object interaction.
>
> Mocking method on the object under test ties your spec to your
> implementation. If you decided to implement 'methodA' in some other way that
> lead to the same behaviour, then your specs shuould still pass. In your case
> they would not.
>
> Cheers
> Nigel
>
> 2009/4/11 Barun Singh <baru...@gmail.com>
>
>> A model I'm trying to spec looks something like this
>>
>> class MyClass
>> def methodA
>> do some stuff
>> methodB
>> end
>>
>> def methodB
>> do some stuff
>> end
>> end
>>
>> my spec looks something like this:
>>
>> x = MyClass.new
>> x.should_receive(:methodB)
>> lambda{ x.methodA }
>>
>> In the situation outlined above, the spec fails. But, if I change the
>> definition of methodA to be as follows the spec passes (note the addition of
>> "self" as the receiver):
>>
>> def methodA
>> do some stuff
>> self.methodB
>> end
>>
>>
>> The code doesn't actually need for me to identify "self" as the receiver
>> on order for it to work. But rSpec seems to require this. Is there an
>> alternative way to write the spec so that it passes in the original case
>> (where I call methodB without an explicit receiver)?
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
