On Fri, Apr 10, 2009 at 6:55 PM, Ashley Moran <ashley.mo...@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. > > HTH > > 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@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
