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

Hierbei gibt es nur ein Problem: Man sieht jedes Mal eine Meldung, wenn eine Datenbank erstellt und gestartet wird. Jedes Mal, wenn man PithyDBDerbyTest einen weiteren Test hinzufügt, werden die Methoden setUp und tearDown ausgeführt, aber das „Erzeugen einer SQL-Datenbank“ ist in jedem Fall ein ressourcenhungriges Unterfangen.

Ganz nach Lehrbuch würde einen die Unit Testing-Methode hier darauf hinweisen, dass die Tests nicht sorgfältig genug aufgeteilt wurden und dass man ein „Pseudo-Objekt“ verwenden könnte, um der PithyDBDerby-Klasse eine Datenbankverbindung vorzugaukeln. Das würde wahrscheinlich umfangreiche Änderungen am Code erfordern. Ein pragmatischer Ansatz bestünde darin, die Zahl der Aufrufe von setUp und tearDown zu reduzieren und nur noch einmal pro Testdurchlauf durchzuführen.

Hierfür muss man wissen, wie JUnit die Tests eigentlich durchführt. Wenn ein TestCase ausgeführt wird, sucht der Test-Runner nach einer „Suite“ mit statischen Methoden, welche einen „Test“ zurückgeben, die Basisklasse für Tests bei JUnit. TestCase ist eine Unterklasse von Test, ebenso eine weitere Klasse, TestSuite, welche verwendet werden kann, um Tests zusammenzufügen. Wenn man die statische Methode in der Suite in einem TestCase überschreibt, kann man seine eigene TestSuite zurückgeben:

Hier wird eine TestSuite aus der Testklasse erzeugt und dann ein TestSetup-Decorator benutzt, um die TestSuite in ihre eigenen setUp– und tearDown-Routinen zu verpacken. Dann muss man noch das PithyDBDerby-Feld als statisch deklarieren und die bisherigen Methoden setUp und tearDown in oneTimeSetup und oneTimeTearDown umbenennen. Diese Version des Tests wurde in PithyDBDerbyTest2.java gespeichert, daher muss man das junit-Element in der Datei build.xml um die folgende Zeile ergänzen und kann die Tests erneut ausführen.

Nun wird die Datenbank nur noch einmal erzeugt, egal wie viele Tests sich im TestCase befinden. Hierbei sollte man aber unbedingt bedenken, dass man nicht mehr so viel Kontrolle über den Status der Datenbank für jeden einzelnen Test hat. Daher muss man sicherstellen, dass sich die Tests nicht gegenseitig beeinflussen.

Wenn man damit beginnt, seinen Code zu überarbeiten, kann man – statt erst Tests und dann neuen Code zu schreiben – Probleme mit älterem Code auch dadurch vermeiden, dass man Tests für das Verhalten schreibt, welches der neue Code erwartet. Dies wäre ein organisches Verfahren, um die Codequalität zu steigern.

Hier können Sie den Code zum Artikel herunterladen.