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

Wenn Sie JUnit verwenden, werfen Sie einen Blick auf junit-addons . Es hat die Fähigkeit, das Java-Sicherheitsmodell zu ignorieren und auf private Methoden und Attribute zuzugreifen.

Answer 2

Ich tendiere dazu, private Methoden nicht zu testen. Das ist der Wahnsinn. Ich persönlich glaube, dass Sie nur Ihre öffentlich zugänglichen Schnittstellen testen sollten (und das schließt geschützte und interne Methoden ein).

Answer 3

Ich würde vorschlagen, dass Sie Ihren Code ein wenig umgestalten. Wenn Sie anfangen müssen, über die Verwendung von Reflexion oder andere Dinge nachzudenken, nur um Ihren Code zu testen, läuft etwas mit Ihrem Code schief.

Sie haben verschiedene Arten von Problemen erwähnt. Beginnen wir mit privaten Feldern. Im Falle von privaten Feldern hätte ich einen neuen Konstruktor hinzugefügt und Felder in diesen injiziert. Anstatt dessen:

public class ClassToTest {

    private final String first = "first";
    private final List<String> second = new ArrayList<>();
    ...
}

Ich hätte das hier benutzt:

public class ClassToTest {

    private final String first;
    private final List<String> second;

    public ClassToTest() {
        this("first", new ArrayList<>());
    }

    public ClassToTest(final String first, final List<String> second) {
        this.first = first;
        this.second = second;
    }
    ...
}

Dies ist selbst bei altem Code kein Problem. Alter Code wird einen leeren Konstruktor verwenden, und wenn Sie mich fragen, wird der überarbeitete Code sauberer aussehen, und Sie werden in der Lage sein, notwendige Werte in Tests ohne Reflexion zu injizieren.

Nun zu den privaten Methoden. Meiner persönlichen Erfahrung nach hat eine private Methode, die man zum Testen stubben muss, in dieser Klasse nichts zu suchen. Ein übliches Muster wäre in diesem Fall, dass man wickeln innerhalb einer Schnittstelle, wie Callable und dann übergeben Sie diese Schnittstelle auch im Konstruktor (mit diesem Trick mit mehreren Konstruktoren):

public ClassToTest() {
    this(...);
}

public ClassToTest(final Callable<T> privateMethodLogic) {
    this.privateMethodLogic = privateMethodLogic;
}

Meistens sieht alles, was ich geschrieben habe, so aus, als ob es sich um ein Dependency Injection Pattern handelt. Meiner persönlichen Erfahrung nach ist es beim Testen sehr nützlich, und ich denke, dass diese Art von Code sauberer ist und leichter zu pflegen ist. Dasselbe würde ich über verschachtelte Klassen sagen. Wenn eine verschachtelte Klasse schwere Logik enthält, wäre es besser, sie als private Klasse in ein Paket zu verschieben und sie in eine Klasse zu injizieren, die sie benötigt.

Es gibt auch einige andere Entwurfsmuster, die ich beim Refactoring und bei der Wartung von Legacy-Code verwendet habe, aber es hängt alles von den zu testenden Fällen Ihres Codes ab. Die Verwendung von Reflection ist meistens kein Problem, aber wenn man eine Unternehmensanwendung hat, die intensiv getestet wird und die Tests vor jedem Einsatz ausgeführt werden, wird alles sehr langsam (das ist einfach ärgerlich und ich mag so etwas nicht).

Es gibt auch Setter Injection, aber ich würde nicht empfehlen, sie zu verwenden. Ich würde besser mit einem Konstruktor bleiben und alles initialisieren, wenn es wirklich notwendig ist, so dass die Möglichkeit für die Injektion von notwendigen Abhängigkeiten.

Answer 4

Hier ist meine generische Funktion zum Testen privater Felder:

protected <F> F getPrivateField(String fieldName, Object obj)
    throws NoSuchFieldException, IllegalAccessException {
    Field field =
        obj.getClass().getDeclaredField(fieldName);

    field.setAccessible(true);
    return (F)field.get(obj);
}

Answer 5

Nachstehend finden Sie ein Beispiel;

Die folgende Importanweisung sollte hinzugefügt werden:

import org.powermock.reflect.Whitebox;

Jetzt können Sie das Objekt direkt übergeben, das die private Methode, den aufzurufenden Methodennamen und zusätzliche Parameter enthält (siehe unten).

Whitebox.invokeMethod(obj, "privateMethod", "param1");