[rspec-users] spec-ing private methods?
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.
Steve Eley (sfeley at gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
More information about the rspec-users