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

Auf eine private Methode darf nur innerhalb der gleichen Klasse zugegriffen werden. Es gibt also keine Möglichkeit, eine "private" Methode einer Zielklasse von einer beliebigen Testklasse aus zu testen. Ein Ausweg ist die manuelle Durchführung von Einheitstests oder die Änderung der Methode von "privat" in "geschützt".

Und dann kann auf eine geschützte Methode nur innerhalb desselben Pakets zugegriffen werden, in dem die Klasse definiert ist. Wenn Sie also eine geschützte Methode einer Zielklasse testen wollen, müssen Sie Ihre Testklasse im selben Paket wie die Zielklasse definieren.

Wenn die oben genannten Punkte nicht Ihren Anforderungen entsprechen, verwenden Sie der Weg der Reflexion um auf die private Methode zuzugreifen.

Answer 2

Wie bereits von vielen vorgeschlagen, ist es eine gute Möglichkeit, sie über Ihre öffentlichen Schnittstellen zu testen.

Wenn Sie dies tun, ist es eine gute Idee, ein Code Coverage Tool (wie Emma) zu verwenden, um zu sehen, ob Ihre privaten Methoden tatsächlich von Ihren Tests ausgeführt werden.

Answer 3

Heute habe ich eine Java-Bibliothek zum Testen privater Methoden und Felder entwickelt. Sie wurde mit Blick auf Android entwickelt, kann aber wirklich für jedes Java-Projekt verwendet werden.

Wenn Sie einen Code mit privaten Methoden, Feldern oder Konstruktoren haben, können Sie BoundBox . Es tut genau das, wonach Sie suchen. Im Folgenden finden Sie ein Beispiel für einen Test, der auf zwei private Felder einer Android-Aktivität zugreift, um diese zu testen:

@UiThreadTest
public void testCompute() {

    // Given
    boundBoxOfMainActivity = new BoundBoxOfMainActivity(getActivity());

    // When
    boundBoxOfMainActivity.boundBox_getButtonMain().performClick();

    // Then
    assertEquals("42", boundBoxOfMainActivity.boundBox_getTextViewMain().getText());
}

BoundBox macht es einfach, private/geschützte Felder, Methoden und Konstruktoren zu testen. Sie können sogar auf Dinge zugreifen, die durch Vererbung verborgen sind. BoundBox bricht in der Tat die Kapselung auf. Sie ermöglicht Ihnen den Zugriff auf all diese Dinge durch Reflection, BUT alles wird zur Kompilierungszeit geprüft.

Es ist ideal für das Testen von Legacy-Code. Verwenden Sie es vorsichtig ;)

https://github.com/stephanenicolas/boundbox

Answer 4

Zunächst möchte ich diese Frage stellen: Warum müssen Ihre privaten Mitglieder isoliert getestet werden? Sind sie so komplex und bieten so komplizierte Verhaltensweisen, dass sie unabhängig von der öffentlichen Oberfläche getestet werden müssen? Es handelt sich um Unit-Tests, nicht um "Line-of-Code"-Tests. Kümmern Sie sich nicht um den Kleinkram.

Wenn sie so groß sind, groß genug, dass diese privaten Mitglieder jeweils eine "Einheit" groß in der Komplexität - erwägen Refactoring solche privaten Mitglieder aus dieser Klasse.

Wenn Refactoring unangemessen oder undurchführbar ist, können Sie das Strategiemuster verwenden, um den Zugriff auf diese privaten Mitgliedsfunktionen/Mitgliedsklassen im Rahmen von Unit-Tests zu ersetzen? Im Rahmen von Unit-Tests würde die Strategie eine zusätzliche Validierung bieten, aber in Release-Builds wäre es ein einfaches Pass-Through.

Answer 5

Ich möchte Ihnen eine Regel vorstellen, die ich über das Testen habe und die besonders mit diesem Thema zusammenhängt:

Ich denke, dass man niemals Produktionscode anpassen sollte, um um das Schreiben von Tests zu erleichtern.

In anderen Beiträgen werden einige Vorschläge gemacht, wie man die Originalklasse anpassen kann, um eine private Methode zu testen. Wenn Sie die Zugänglichkeit einer Methode/eines Feldes in package private oder protected ändern, nur um sie für Tests zugänglich zu machen, dann vereiteln Sie den Zweck der privaten Zugriffsrichtlinie.

Warum sollten wir überhaupt private Felder/Methoden/Klassen haben, wenn wir eine testgetriebene Entwicklung haben wollen? Sollten wir alles als Paket privat oder sogar öffentlich deklarieren, damit wir ohne Aufwand testen können? - Das glaube ich nicht.

Aus einem anderen Blickwinkel betrachtet. Tests sollten die Leistung und Ausführung der Produktionsanwendung nicht beeinträchtigen. Wenn Sie den Produktionscode ändern, nur um die Tests zu vereinfachen, können Sie die Leistung und die Ausführung der Anwendung in irgendeiner Weise beeinträchtigen. Und wenn man anfängt, den privaten Zugriff auf das Paket private zu ändern, kann man schließlich auf "geniale Ideen" kommen, um der ursprünglichen Klasse weiteren Code hinzuzufügen, der die Lesbarkeit zusätzlich beeinträchtigt und die Leistung der Anwendung beeinträchtigen kann.

Andererseits eröffnen Sie mit der Änderung des privaten Zugriffs in einen weniger restriktiven Zugriff einem Entwickler die Möglichkeit, eine neue Situation bei der künftigen Entwicklung der Anwendung zu missbrauchen. Anstatt ihn zu zwingen, auf die richtige Art und Weise zu entwickeln, eröffnen Sie ihm neue Möglichkeiten und geben ihm die Fähigkeit, in Zukunft falsche Entscheidungen zu treffen.

Natürlich kann es ein paar Ausnahmen von dieser Regel geben, aber man sollte sich darüber im Klaren sein, was die Regel und was die Ausnahme ist und warum sie gemacht wird.