[rspec-users] message expectations without explicit receiver

David Chelimsky dchelimsky at gmail.com
Fri Apr 10 17:57:48 EDT 2009

On Fri, Apr 10, 2009 at 6:55 PM, Ashley Moran
<ashley.moran at patchspace.co.uk> wrote:
> On 10 Apr 2009, at 22:27, Barun Singh wrote:
>> 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
> Hi Barun
> The situation you describe is a violation of the Single Responsibility
> principle.  Your *class*, never mind your method, is doing too much.

Agreed. FWIW.

>> 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.
> What you need to do is figure out how you can isolate parts of the algorithm
> and spec them as separate objects.  That way you can mock out the other
> bits, and cut down the permutations you need to cover to prove the app still
> works.
> Excessive build-up of logic branches is something I struggled with for a
> long time, and it still bit me recently.  But, in my experience, it's always
> just a code/spec smell.  As soon as the specs get too complex to understand,
> find a simpler way of expressing you problem.  This can be either by
> refactoring with standard OO techniques, or - if that fails to reduce the
> complexity - fundamentally re-modelling the problem.
> Ashley
> --
> http://www.patchspace.co.uk/
> http://www.linkedin.com/in/ashleymoran
> http://aviewfromafar.net/
> http://twitter.com/ashleymoran
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list