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

Nun kann die Klasse neu kompiliert und der Test wieder durchführt werden:

Diesmal war der Test erfolgreich. Natürlich ist es nicht optimal, die Tests jedes Mal manuell aufrufen zu müssen. Der Rest von JUnit befasst sich damit, wie man die Ausführung dieser TestCases organisiert, sowie mit unterschiedlichen Möglichkeiten, die Ergebnisse dieser Tests darzustellen. Obwohl JUnit – wie der Name schon sagt – vor allem für Unit Testing gedacht ist, ist das Framework doch so allgemein gehalten, dass man es auch für „größere“ Einheiten als einzelne Klassen verwenden kann.

Anhand eines Beispiels aus einem früheren Artikel – Pithy (aus „Eingebettete SQL-Datenbank in Java„) – soll gezeigt werden, wie man JUnit zum Build-Prozess hinzufügt und einige Tests erstellt.

Der Build von Pithy erfolgt mithilfe von Apache Ant, für das JUnit-Unterstützung als optionales Paket vorhanden ist. Wenn sich junit.jar im Klassenpfad befindet, sollte Ant es automatisch finden, aber wenn man seinen Default-Klassenpfad nicht verwenden möchte (was sich empfiehlt, wenn man einen Code-Tree mit minimalen externen Abhängigkeiten haben will), besteht die einfachste Methode zur Aktivierung darin, die Datei junit.jar in das Verzeichnis $ANT_HOME/lib zu kopieren. Damit ist die Ant-Task <junit> aktiviert.

Sobald alles eingerichtet ist, kann man die Testklassen organisieren. Statt den Testcode mit dem eigentlichen Code zu vermischen, ist es besser, eine separate Testhierarchie mit ihrem eigenen Klassenbaum anzulegen. Hier der Anfang der Datei build.xml:

Hier werden die Eigenschaften testDir und testOutputDir festgelegt (und anders als bei der Original-Build-Datei werden das init-Target entfernt und alle Eigenschaften bereits festgelegt). Dann werden zwei Klassenpfad-Variablen definiert: eine mit dem Klassenpfad zur Ausführung von Pithy und eine, welche neben diesem Klassenpfad auch die Testklassen enthält. Als Nächstes muss man ein Target hinzufügen, um alle vorhandenen Tests zu kompilieren.