On Wed, Oct 14, 2009 at 3:49 PM, Scott Taylor <sc...@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 (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
