If a user of my module isn't supposed to use the method, then it's private, subject to change without notice. However, my subclasses will probably want to override some subset of these private methods because that's where the meat of the work is happening.

I guess we have different definitions of private then. If somebody needs to know about and understand a method to be able to subclass a something successfully then I would want that documented and available to all - rather than buried in the source.

When I write OO code I do not want to have to read all the source of my superclasses. To me that's one of the advantages of abstraction and encapsulation :-)

Furthermore, inside-out objects don't play well with most other uses, such as shared memory, DBM::Deep or other introspective situations.

For me the advantages outweigh the disadvantages (and things like Class::InsideOut deal with most of the latter.)

Another issue is that your tests may not be valid for subclasses.

True - but I think that would mean:

• I'm testing something that's not intended to be subclassed - so I don't care.
• I've made a mistake in the design - since subclasses should be a specialisation of their super class. That's what an isa relationship says to me.

I'm not saying that it's always a good idea to install test classes - I just don't think it's always a bad idea either :-)