Das Testen von private-Methoden unter Java ist nicht immer ganz einfach. Diese kann man entweder nur undirekt testen, was das Schreiben von Unit-Tests erheblich verkompliziert. Oder man verwendet die Reflection API und schaltet die ReflectPermission aus. Wirklich Spass macht auch dieses Vorgehen nicht. Bleibt als Alternative die Möglichkeit die private-Methoden durch protected-Methoden zu ersetzen. Testsysteme können dann von diesen ableiten und diese dann public machen, wenn die Methoden nicht zusätzlich auch noch final sind. Nachteilig ist hier, dass eigentlich für die API nicht wichtige Methoden nach aussen sichtbar sind.

Die Lösung liegt im anlegen von 2 Codeebenen. Eine für den eigentlichen Quellcode und eine für den Testcode, der später nicht mit ausgeliefert wird. In beiden Ebenen wird die gleiche Packagestruktur aufgebaut. Beiden Ebenen werden nacheinander in unterschiedliche Binärverzeichnisse compiliert, wobei die Testebene als letztes dran kommt. Über den Classloader werden jetzt beide Ebenen wieder zusammen geführt und die Testcases ausgeführt. private-Methoden lassen sich auch so nicht einfach testen. Da aber Packagestrukturen im allgemeinen nicht ausufernd komplex sind ist es durchaus zulässig alle private-Methoden als package-private, also ohne Sichtbarkeitsmodifikator, zu implementieren. Die Testklassen können jetzt auf diese Methoden ohne Umwege zugreifen und deren Verhalten testen.

Mit diesem Kniff gibt man einen kleinen Teil des Geheimnisprinzips des OO-Paradigmas preis, erhält im Gegenzug aber übersichtlichere und höherwertige Tests und damit bessere Software. Ich gehe jetzt seit mehreren Jahren bei der Entwicklung so vor und habe noch keine Nachteile feststellen können.

Im Prinzip ist der private-Sichtbarkeitmodifikator unter Java überflüssig.