[rspec-users] message expectations without explicit receiver
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
>> * 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
> 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.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users