On Fri, 3 Aug 2007, David C. wrote:
The advantage of allowing send to access private methods is that it
- If you’re doing TDD, you’re sending messages to objects that other
My sense is that some of this thinking is a product of the fact that
testing privates in Java means using reflection, resulting in
refactoring inefficiencies. In Ruby, testing privates is fairly easy
and we don’t really have the refactoring tools that the Java community
has, so refactoring in Ruby tends to be much more manual anyhow.
That said, I think the OO design questions that get raised are worthy
of exploration when you feel the need to test something private.
My tendency is to think that the public/private distinction in Ruby
does not overlap very closely with the line between methods you’re
likely to use from outside and methods you’re not, mainly for two
First, private instance methods of Kernel, like raise and sprintf:
these are not behind the black curtain, but are private so as to be
callable in a receiverless way. I’d expect them to be tested.
Second, quick and frequent scope and self-scope changes:
etc. define_method, like raise and sprintf, won’t go away because of
refactoring; it’s a private method, but part of the interface one is
expected to use (rather than simply a by-product of the implementation
of some other such method).
That said, it may be that there are private methods one wouldn’t test,
namely those that are really part of the black box, where all you
really need to know is whether the black box produces the right
answer. But I think that’s just a subset of private methods,
certainly in core/standard Ruby and quite possibly in other Ruby code.