Nachträglicher Einsatz von JUnit zum Testen von älterem Code

Und schließlich das Herzstück des Testprozesses: <junit>-Task.


Der Klassenpfad wird auf denselben Wert gesetzt wie der, der zur Kompilierung der Testklassen verwendet wird. Das formatter-Element ermöglicht es anzugeben, wie die Testergebnisse angezeigt werden sollen. Wenn das Attribut type auf „brief“ gesetzt ist, werden nur Informationen über fehlgeschlagene Testfälle angezeigt. Weitere Optionen sind „xml“ für die Weitergabe an andere Prozesse oder „plain“, welches die Ergebnisse sämtlicher durchgeführter Tests ausgibt. Standardmäßig erfolgt die Ausgabe in eine Datei (basierend auf dem Namen des durchgeführten Tests), daher wird das Attribut usefile auf „false“ gesetzt, so dass man die Ergebnisse am Bildschirm sehen kann.

Und schließlich kann man noch beliebig viele test-Elemente einfügen. Diese übernehmen als Attribut den Namen der auszuführenden Testklasse. Im obigen Codebeispiel soll com.runstate.pithy.PithTest ausgeführt werden. Diese Datei sollte sich in tests/com/runstate/pithy/PithTest.java befinden. Warum wurde sie im selben Paket erstellt wie die zu testende Klasse? Nun, einmal kann man sich dies einfacher merken, es bietet aber auch die Möglichkeit, dass der Testfall private Methoden des Pakets testen kann und nicht nur die normalerweise sichtbaren Methoden, und weil die Tests vom Produktionscode getrennt wurden, besteht trotzdem nicht die Gefahr, dass der Produktionscode mit Testcode aufgebläht wird.

Die PithTest-Klasse ist nur eine einfache Unit-Test-Klasse zum Testen von Gleichheitsoperationen mit Pith. Wenn man jetzt „ant test“ durchführt, kompiliert ant den Code, dann den Testcode, führt diesen aus und berichtet das Ergebnis dieses Tests.


Damit ist das grundlegende Framework zur Durchführung von Tests eingerichtet. Der eigentliche Test dieses Beispiels für nachträgliches Testen ist das Testen der Datenbankklasse PithyDBDerby.java. (Eine kleine Änderung an der PithyDB-Schnittstelle gegenüber dem Original ist die Fähigkeit, die Datenbank auch leer starten zu können, so dass sie in einen bekannten Status zurückversetzt werden kann.)

Themenseiten: Anwendungsentwicklung, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Nachträglicher Einsatz von JUnit zum Testen von älterem Code

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *