[rspec-users] spec-ing private methods?

Stephen Eley sfeley at gmail.com
Wed Oct 14 16:31:00 EDT 2009

On Wed, Oct 14, 2009 at 3:49 PM, Scott Taylor <scott at railsnewbie.com> wrote:
> Most of those options suck (esp. 1, 2, 3, & 4) - usually it represents a
> design flaw (you are doing too much in your class).

I disagree that the simple existence of private methods is a sign of a
design flaw.  There are plenty of use cases for which private methods
are the simplest and most practical approach.  I use them all the time
to help me deconstruct complicated multi-step actions into shorter,
more atomic chunks of logic.  They're also how callbacks and filters
are usually implemented in Rails.

That said, though: I usually don't bother testing them.  I use RSpec
for unit testing, and when I'm doing that I care about the _external
behavior_ of the unit.  I want to know what the object will do when I
poke it from another object.  Private methods are an implementation
detail, not a "What does it do?" but rather "How does it do that?" --
and that's not any other class's business.

They're also not usually that complex or brittle.  I'll know they work
because the public or protected methods that call them work; and I
don't need tests to understand them. In the exceptional cases where
they _might_ be complex (e.g., some ActiveRecord callbacks or
authentication filters) you're right -- putting them into a module and
testing that module makes sense.

Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine

More information about the rspec-users mailing list