[rspec-users] message expectations without explicit receiver

Ashley Moran ashley.moran at patchspace.co.uk
Fri Apr 10 17:55:52 EDT 2009

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.

> 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  




More information about the rspec-users mailing list