Ah, it was a red herring indeed... I was using the lambda because my actual
test was like:
lambda {x.methodA}.should raise_error
The problem was that an error was being raised before I expected it to be
raised, and before "methodB" was ever called. I thought calling the
explicit "self" receiver made a difference only because I was generating
some random data for my tests that by chance didn't fail when I made that
change (this hole in the test data is fixed now).
Re: the more general code design --
In general the code does obey the Single Responsibility Principle, but this
particular class I'm spec'ing right now doesn't do that so well. I suspect
you're right that it would be worthwhile to look at how to better split
responsibilities into new classes. The specs themselves are proving to be
helpful in determining where and how things could be refactored.
Thanks (and sorry for the non-issue problem).
On Fri, Apr 10, 2009 at 5:57 PM, David Chelimsky <dchelim...@gmail.com>wrote:
> 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
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
