On Jan 9, 2008 5:26 AM, Richard Conroy <[EMAIL PROTECTED]> wrote:
> On Jan 8, 2008 7:14 PM, Daniel Tenner <[EMAIL PROTECTED]> wrote:
> > Might be a personal thing, but my approach is that I try to test the
> > public behaviour of the object. Testing private methods is, imho,
> > getting dangerously close to specifying how the object does its
> > business, rather than what it does.
> >
> > I would just spec the externally visible behaviour, where it occurs,
> > and let the object implement it as it wants (using private methods or
> > any other mechanism).
>
> The trouble is that this makes it very difficult to get effective coverage.
> There is usually a lot more setup involved. If your tests are more expensive
> to write, because you are unit testing indirectly through public methods,
> less testing will get done, and worse tests can end up getting very brittle.

I've found that this is symptomatic of a bad design.  Specifically, it
smells of an SRP violation or tight coupling.

One thing I think people don't realize is that a bit of code should be
easiest to use in a test.  We test objects in isolation, they don't
depend on expensive external resources, etc.  If you can't use the
code within a test harness - that is, write a test for it - then how
can you possibly expect to use it in production?

In practice, of course, this can all be very difficult.  I recommend
reading "Working Effectively with Legacy Code" by Michael Feathers for
some excellent strategies on how to make existing gnarly code easier
to test.


> I do like the idea though of during the unit test itself, you unseal the 
> method.
> You get the best of both worlds.

Not really.  You get test coverage, which is good, but at the expense
of carefully thinking why your design might be wrong.

Pat
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to