Wie teste ich eine Klasse, die private Methoden, Felder oder innere Klassen hat?

Question

Wie kann ich mit JUnit eine Klasse testen, die interne private Methoden, Felder oder verschachtelte Klassen hat?

Es scheint schlecht, den Zugriffsmodifikator für eine Methode zu ändern, nur um einen Test durchführen zu können.

Answer 1

Aktualisierung:

Etwa 10 Jahre später ist der beste Weg zum Testen einer privaten Methode oder eines unzugänglichen Elements vielleicht die Verwendung von @Jailbreak von der Verteiler Rahmen.

@Jailbreak Foo foo = new Foo();
// Direct, *type-safe* access to *all* foo's members
foo.privateMethod(x, y, z);
foo.privateField = value;

Auf diese Weise bleibt Ihr Code typsicher und lesbar. Keine Kompromisse beim Design, keine Überbelichtung von Methoden und Feldern um der Tests willen.

Wenn Sie eine Art Erbe haben Java Anwendung, und Sie dürfen die Sichtbarkeit Ihrer Methoden nicht ändern, ist der beste Weg, um private Methoden zu testen, die Verwendung von Reflexion .

Intern verwenden wir Helfer zum Holen/Setzen von private y private static Variablen sowie den Aufruf von private y private static Methoden. Mit den folgenden Mustern können Sie so ziemlich alles tun, was mit den privaten Methoden und Feldern zu tun hat. Natürlich können Sie nicht ändern private static final Variablen durch Reflexion.

Method method = TargetClass.getDeclaredMethod(methodName, argClasses);
method.setAccessible(true);
return method.invoke(targetObject, argObjects);

Und für Felder:

Field field = TargetClass.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(object, value);

---

注意事項
1. TargetClass.getDeclaredMethod(methodName, argClasses) ermöglicht Ihnen einen Blick in private Methoden. Das Gleiche gilt für getDeclaredField .
2. Die setAccessible(true) ist erforderlich, um mit Privaten herumzuspielen.

Answer 2

Der beste Weg, eine private Methode zu testen, ist eine andere öffentliche Methode. Wenn dies nicht möglich ist, dann ist eine der folgenden Bedingungen erfüllt:

1. Die private Methode ist toter Code
2. In der Nähe der Klasse, die Sie testen, gibt es einen Designgeruch
3. Die Methode, die Sie testen wollen, sollte nicht privat sein

Answer 3

Wenn ich private Methoden in einer Klasse habe, die so kompliziert sind, dass ich das Bedürfnis habe, die privaten Methoden direkt zu testen, ist das ein Codegeruch: Meine Klasse ist zu kompliziert.

Mein üblicher Ansatz zur Lösung solcher Probleme besteht darin, eine neue Klasse zu entwickeln, die die interessanten Teile enthält. Oft können diese Methode und die Felder, mit denen sie interagiert, und vielleicht eine oder zwei weitere Methoden in eine neue Klasse extrahiert werden.

Die neue Klasse stellt diese Methoden als "öffentlich" dar, damit sie für Unit-Tests zugänglich sind. Die neue und die alte Klasse sind nun beide einfacher als die ursprüngliche Klasse, was für mich großartig ist (ich muss die Dinge einfach halten, sonst verliere ich den Überblick!)

Damit will ich nicht sagen, dass man Klassen erstellen soll, ohne sein Gehirn zu benutzen! Es geht hier darum, die Kräfte der Unit-Tests zu nutzen, um gute neue Klassen zu finden.

Answer 4

Ich habe verwendet Reflexion Ich habe in der Vergangenheit versucht, dies für Java zu tun, und meiner Meinung nach war das ein großer Fehler.

Streng genommen sollten Sie no Unit-Tests schreiben, die private Methoden direkt testen. Was Sie sollte Bei den Tests, die Sie durchführen, geht es um den öffentlichen Vertrag, den die Klasse mit anderen Objekten hat; Sie sollten niemals direkt die Interna eines Objekts testen. Wenn ein anderer Entwickler eine kleine interne Änderung an der Klasse vornehmen möchte, die sich nicht auf den öffentlichen Vertrag der Klasse auswirkt, muss er/sie Ihren reflektionsbasierten Test ändern, um sicherzustellen, dass er funktioniert. Wenn Sie dies im Laufe eines Projekts immer wieder tun, sind Unit-Tests kein nützlicher Gradmesser mehr für den Zustand des Codes, sondern werden zu einem Hindernis für die Entwicklung und zu einem Ärgernis für das Entwicklungsteam.

Ich empfehle stattdessen die Verwendung eines Codeabdeckungstools wie Cobertura, um sicherzustellen, dass die von Ihnen geschriebenen Unit-Tests eine angemessene Abdeckung des Codes in privaten Methoden bieten. Auf diese Weise testen Sie indirekt, was die privaten Methoden tun, und erhalten ein höheres Maß an Agilität.

Answer 5

Aus diesem Artikel: Private Methoden mit JUnit und SuiteRunner testen (Bill Venners), haben Sie im Grunde 4 Möglichkeiten:

1. Testen Sie keine privaten Methoden.
2. Geben Sie den Methoden Paketzugang.
3. Verwenden Sie eine verschachtelte Testklasse.
4. Reflexion verwenden.