Was ist JUnit?

...komplette Frage anzeigen

2 Antworten

Ergänzung zu DieLuka:

Der erste Link gibt dir einen sehr guten Einstieg über die technischen Möglichkeiten bei JUnit. Im Grunde ist das mittlerweile derart alt (nicht im Sinne von Altbacken), dass sich an dieses Framework zig gute Erweiterungen angliedern. Es gibt quasi nichts, was es nicht gibt.

Deswegen sollte man JUnit nicht mehr als "Unit Test Framework" beschreiben, sondern nur noch als "Test Framework" allgemein. Es gibt einige unterschiedliche Strategien, wie getestet wird, um die Software-Qualität sicher zu stellen. Über allem steht, wie korrekterweise im Link beschrieben, dass ein Test von Hand (also mit dir als Akteur) extrem zeitaufwändig ist, da du die Tests immer wiederholen musst. Ein automatisierter Test kann auf Knopfdruck gestartet werden oder auch beispielsweise von einem Server, sobald im SVN etwas geändert wurde. (Stichwort continuous integration).

* Mit Blackbox-Test schreibst du die Tests ausschließlich gegen die API, also gegen die Klassen und Methoden, die dir angeboten werden. Dir ist kein Blick in den Quellcode gestattet.

* Mit Whitebox-Tests darfst du in den Quellcode schauen, um deine Tests zu schreiben. Du schreibst ihn also gegen konkrete Implementierungen.

* Daneben gibt es noch reine Unit-Tests. Dabei schreibst du Tests für ein spezielles kleines Teil aus deinem ganzen Programm. Üblicherweise wird eine Unit mit einer Methode aus einer Klasse gleichgesetzt. Wenn deine Klasse andere Klassen braucht, sollte beim Unit-Tests deren verhalten simuliert werden (Stichwort Mock).

* Als Pendant zu den Unit-Tests gibt es Integrations-Tests. Diese gehen den umgekehrten Weg von Unit-Tests, sie testen stattdessen eine ganze Komponente. Und wenn diese eine Komponente andere braucht, werden diese nicht gemockt, sondern stattdessen wird das Original genutzt.

Da das Unit-Testing eine Strategie ist, sollte man auch mit JUnit vom Namen her das ganze nicht verwechseln. Ursprünglich war es wie gesagt zum Unit-Testen angelegt. Mittlerweile kannst du mit verschiedensten Zusatz-Erweiterungen aber alles machen, bis hin zum Testen einer Webseite mit hinten dran konfigurierter Server-Landschaft usw.

Das Wichtigste zuerst: Alle Strategien machen immer auch Sinn. Wichtig ist nicht, welche Strategie man vorschreibt, sondern wichtig ist, dass man die besten Strategie nimmt, die für den konkreten Test gerade Sinn ergibt. Gerade besondere Tool-Klassen, die besondere Berechnungen vornehmen, sind oft Kandidaten für Unit-Tests. Sie haben auch oft keine Abhängigkeiten zu anderen Komponenten. Daneben kann es aber gute Gründe geben, warum eine Komponente, die richtig eng verzahnt ist, nur einen vollumfassenden Integrationstest durchläuft. Je mehr man mocken müsste, also vom System simulieren müsste, damit man es getestet bekommt, desto eher sollte von vom Unit-Test abkommen. Es gibt sogar mittlerweile Verfechter, die jegliches Mocken für Werkzeug des Teufels halten :-)

Bei White-Box Tests hast du den großen Vorteil, dass deine Tests auch wirklich das abdecken, was technisch fabriziert wird. Man kann mit verschiedensten Tools (Stichwort Code-Coverage) schauen, welche Code-Zeilen durchlaufen werden oder welche nicht. Mit einem Black-Box-Test allerdings entdeckst du womöglich Dinge, die dein Code gar nicht berücksichtigt, die aber für deinen Aufrufer Sinn ergeben. Auch wenn später die Methode verändert wird, können die Blackbox-Tests aufzeigen, dass du an etwas nicht gedacht hast bei den Umbauten. Im Grunde aber ist auch hier immer eine Kombination sinnvoll.

Beispiel: Du kannst dir 30 Testfälle bauen, die dir prüfen, ob Math.min korrekt funktioniert. Aber wenn die 30 Tests sich nur dadurch unterscheiden, dass die Zahlen verändert werden, aber trotzdem stets links die niedrigere Zahl von beiden steht, dann hilft dir ein Blick auf den Code, dass vielleicht eine Code-Zeile nicht durchlaufen wird. Dann schreibst du vielleicht auf einen Test, in dem mal die größere Zahl links steht. Oder einen Test, wo du zwei mal dieselbe Zahl übergibst. Ob nun Whitebox-Tests oder Blackbox-Tests. Man sollte sich IMMER Gedanken machen, welche Tests sinnvoll sind und welche nicht und zwar sowohl bei Betrachten der Schnittstelle (Blackbox) als auch beim betrachten des Code-Coverage der bisherigen Tests.

Antwort bewerten Vielen Dank für Deine Bewertung

Was möchtest Du wissen?