This feels like the same conversation we had earlier this week about
accessing private methods. :) But maybe there are still a few new
points that can be made.

Tom (>>), Moritz (>):
>> I need to test some private routines, so is there a way to do that?
> The easiest way to do that is when the class with the private methods
> trusts the class that calls them. See for example

I would consider all usages of `trusts` a code smell, if nothing else
than for the reason that it links your upstream producer (your class)
to a downstream producer (your tests), and explicitly talking about
something downstream creates an unholy coupling to it, *and* is
difficult because you have to predeclare it in some way.

> But you should ask yourself if you really, really want this.
> And then you can also do something like:
> my $private_method = $obj.^private_method_table{$methodname};
> $obj.$private_metnod(arguments here)
> but it is rather questionable use of the MOP.

I would actually use $obj.^find_private_method, as I showed in that
other thread:

    class C { method !foo { say "OH HAI" } }; my $obj =; my $pm
= C.^find_private_method("foo"); $obj.$pm

But I would also amend moritz' "rather questionable" by saying that if
you do this, even from the comfort of your own tests, you waive
certain advantages of good OOP that you then won't get back.

That little '^' means "time to cheat" -- if private methods are the
walls of a labyrinth preventing you from going wrong, the '^' just
took you to "cheat mode" and you can survey the whole labyrinth from
above. In my opinion, tests shouldn't have to resort to that. A very
small list of things require cheat mode. Tests don't.

The reason we deal with all this inside/outside stuff and make some
things private, is so that we can reserve the right to evolve them
without breaking anything on the outside. Like a
<>, the insides are supposed
to be able to move without creating any friction on the outside.

Any kind of coupling with the outside makes that kind of frictionless
evolution harder. Going to the MOP to break the privacy couples the
tests to the implementation.

Beyond that, this simply *shouldn't need to happen* if the tests are
written by the same person as the implementation.

(A) Either you need to test the method, and then it can happily be
made public, or be made an our sub, or a sub outside of the class.
(B) Or you keep the method private, but find some other way to test it
besides calling it directly.

The goal here is to write tests that don't break in the future. In a
way, this is what good OOP leads to. Coupling your tests to private
methods is a mistake, IMHO. Perl 6 makes this difficult because it's
not a good idea.

// Carl

Reply via email to