JUnit und private Methoden testen.

[needInput]

Ich lerne JUnit erst seit kurzem und möchte gerne das return einer privaten Methode testen.
Die private Methode wird in der Methode aufgerufen, welche ich testen möchte.

//zu testende Methode ist jump
public void jump(Board board){
    //this.sortingHashMapByValue ist die private Methode bei der ich testen möchte,
    //ob die Hashmap sortiert zurück kommt.
    LinkedHashMap<TransportNode, Double> sortedPlaces = this.sortingHashMapByValue(closestPaths);
}

Wie komme ich an die Liste in meiner Test Klasse ran, welche sortingHashMapByValue zurückliefert?

Danke schon einmal im Voraus

 

[httpdigest]

Wie komme ich an die Liste in meiner Test Klasse ran, welche sortingHashMapByValue zurückliefert?

Gar nicht. Man testet keine privaten Methoden, sondern ausschließlich die öffentliche Schnittstelle bzw. das beobachtbare Verhalten einer Klasse.

 

[needInput]

Oh, dachte an Reflection.
Aber wenn man die nicht testet weniger Arbeit für mich. Danke

 

[needInput]

beobachtbare Verhalten einer Klasse.

du sagst beobachtbares Verhalten einer Methode, wie werden void Methoden dann getestet?

 

[thecain]

in dem du schaust, ob sie das verändert haben was sie sollen.

 

[Barista]

Du kannst den privaten Teil in eine eigene Klasse auslagern.

In Deiner eigentlichen Klasse ist die dann in einer lokalen Variable oder privaten Member.

Das Zusammenbauen von neuer und alter Klasse ist dann zwar wiederum ungeprüft, aber Du hast ja außerdem Tests für Deine äußere Klasse.

 

[thecain]

Wieso sollte er das machen? Das macht doch keinen Sinn nur! für die Testbarkeit eine eigene Klasse zu machen.

Die private Methode wird sowieso aufgerufen und durchlaufen, wenn die public Methoden getestet werden. Falls nicht, kann er sie ja bedenkenlos einfach löschen.

void Methoden können entweder dadurch getestet werden, dass geprüft wird, ob sich der State der Klasse entsprechend geändert hat oder, falls Methoden anderer Klassen aufgerufen werden, in dem man die anderen Klassen mockt oder spyt.

 

[mihe7]

du sagst beobachtbares Verhalten einer Methode

Nein, er schrieb das beobachtbare Verhalten einer Klasse. Mach nicht den Fehler, Tests für Methoden zu schreiben. Man testet keine Methoden, man implementiert Testfälle, die Methoden verwenden. Das ist ein kleiner Unterschied, der große Auswirkungen hat.

Sagen wir mal, Du möchtest Tests für eine Liste schreiben. Dann wird die Klasse eine Methode für das Hinzufügen, sagen wir mal add, und Du wirst wenigstens einen Test für das Hinzufügen schreiben. Der Test testet aber nicht die Methode add() sondern das Hinzufügen. Hier sind schon einmal zwei grundsätzliche Fälle zu unterscheiden:
1. das Element war vor dem Hinzufügen bereits in der Liste vorhanden. Dann soll sich durch das Hinzufügen die Liste nicht verändern.
2. das Element war vor dem Hinzufügen noch nicht in der Liste, dann soll es nach dem Hinzufügen in der Liste sein, die Zahl der Elemente muss sich um 1 erhöht haben (und - wenn man will - der Rest der Liste darf sich nicht geändert haben).

Dafür kannst Du jeweils einen oder mehrere Tests schreiben. Diese decken dann aber nicht nur add() ab, sondern auch equals(), contains() und size(). Ein weiterer, davon unabhängiger Testfall könnte sein, dass eine neue Liste leer sein soll: isEmpty() und size() == 0.

Damit ist size() bzgl. neuer Listen und hinzugefügter Elemente bereits erschlagen. Du schreibst also nicht Tests für Methoden (testAdd, testSize, testContains, testEquals, testMethodeX, ...), sondern für das Verhalten.

 

[Barista]

Wieso sollte er das machen? Das macht doch keinen Sinn nur! für die Testbarkeit eine eigene Klasse zu machen.

Es geht um separation of concerns.

Wenn man eine private Methode testen will, steckt darin wahrscheinlich eine testwürdige Funktionalität, die in der äusseren Klasse verbaut ist.

Durch eine eigene Klasse kann man diese Funktionalität explizit machen.

Eigentlich sollte Testbarkeit auch die Struktur verbessern.

Ich persönlich finde dies aber auch etwas seltsam.

Es wäre schon ganz gut, wenn Tests Sonder-Rechte hätten.

 

[mrBrown]

Es geht um separation of concerns.

Wenn man eine private Methode testen will, steckt darin wahrscheinlich eine testwürdige Funktionalität, die in der äusseren Klasse verbaut ist.

Durch eine eigene Klasse kann man diese Funktionalität explizit machen.

Da nahezu alles testwürdige Funktionalität ist, hätte man am Ende pro privater Methode eine eigene Klasse. Dann hätte ich am Ende zehn mal so viele Klassen, und darunter so sinnvolle wie class LinkedListHeadCheck { boolean isHead(Node node) {return node.next == node && node.prev == node}}, für die ich extra die Kapselung aufweichen müsste...

Es wäre schon ganz gut, wenn Tests Sonder-Rechte hätten.

Im Zweifel nutzt man package-private und Annotiert das entsprechend, dass statische Checks bei missbrauch Fehler werfen.