[rspec-users] specs on private methods

Zach Dennis zach.dennis at gmail.com
Fri Jan 11 10:35:47 EST 2008


On Jan 11, 2008 5:23 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jan 11, 2008 3:49 AM, Shot (Piotr Szotkowski) <shot at hot.pl> wrote:
> > Daniel Tenner:
> >
> > > 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 agree on principle, but I ran into the following case in my PhD:
> >
> > There's a Decomposition class that decomposes an FSM to a given
> > architecture. Its public methods should be new() and decompose!().
> > Now, decompose!() works by running a private method by_input_sets!()
> > many times with different parameters.
> >
> > One run of by_input_sets!() takes a couple of seconds, so can be tested;
> > one run of decompose!() takes much longer, so to test decompose!()
> > I should stub by_input_sets!() so it returns canned data (right?).
> >
> > In this situation, I think I do need to test/spec the by_input_sets!()
> > private method – otherwise there would be no code that would check on
> > the way it works.
>
> In TDD there is a rule of thumb that says don't stub a method in the
> same class as the method you're testing.

A simple rule I follow: Don't stub or mock the object under test.

On Jan 11, 2008 9:04 AM, Shot (Piotr Szotkowski) <shot at hot.pl> wrote:
>
> What about the general issue of a slow method that is fast enough to be
> testable in isolation, but some other method from the same class calls
> it so many times that it needs to be stubbed for that method to be
> spec'd in a sane manner?

In addition to David's response to this, have you evaluated moving
this method and its responsibility to its own object that could be
tested in isolation, allowing you to not break the "don't stub or mock
the object under test" guideline?

-- 
Zach Dennis
http://www.continuousthinking.com


More information about the rspec-users mailing list