Mit Test-Driven-Development Bugs schon während der Programmierung vermeiden

Nun können die Tests geschrieben werden, bevor auch nur eine einzige Zeile des zu testenden Codes vorhanden ist. Die Tests werden als Richtschnur für die eigentliche Entwicklung dienen. Dafür wird für jede der einzelnen Varianten eine Test-Methode geschrieben (Listing B).

Diese einfache Methode wird bei der Ausführung die Methode formatDate aufrufen und ihr null als Parameter übergeben. Die Methode assertNotNull wird überprüfen, ob der Ausgabewert null ist. Die anderen Fälle funktionieren ähnlich (Listing C). Die Methoden namens assert* werden vom JUnit-Framework bereitgestellt und vereinfachen so den Vergleich zwischen erwartetem und tatsächlichem Ergebnis erheblich.

Es gibt jetzt also sechs Tests, die alle Fälle abdecken, mit denen es die Methode formatDate erwartungsgemäß zu tun haben wird. Diese Tests werden entsprechend den üblichen JUnit-Konventionen in eine Klasse FormatDateTester geschrieben. Das Durchführen dieser Tests mit JUnit ist recht einfach, wie Listing D zeigt.

Die Methode formatDate sieht im Moment so aus:

Dies dient nur zur Gewährleistung, dass die Klasse mit den Testfällen auch kompiliert wird. Bei Ausführung dieser Tests mit dem Swing-basierten Test-Runner sollte man eine Anzeige ähnlich der in Abbildung A erhalten.

Fehlgeschlagene Tests

Der dicke rote Balken zeigt an, dass einige Tests fehlgeschlagen sind. In diesem Fall waren dies alle Tests. Das ist gut so, denn damit sind die ersten beiden Schritte des oben skizzierten Entwicklungszyklus’ abgeschlossen.

Nun müssen einige Änderungen am Code vorgenommen werden – besser gesagt muss er überhaupt erst geschrieben werden – bis dieser alle Tests besteht.

Zuerst muss die Methode formatDate so modifiziert werden, dass sie die Tests besteht. Während der Entwicklung des Codes von formatDate sollte man regelmäßig die Testfälle ausführen. Dabei werden unweigerlich einer oder mehrere Tests fehlschlagen. Wenn alle Tests bestanden sind, hört man sofort mit dem Programmieren auf. Dank der vorher geschriebenen Tests tut der Code jetzt genau das, was von ihm erwartet wird und nichts anderes.

Der letzte Schritt im Entwicklungszyklus ist das Refactoring des Codes. Man sollte versuchen, jeglichen redundanten Code zu entfernen und Optimierungen in Sachen Performance vorzunehmen. Danach führt man noch einmal die gesamte Test-Suite aus. Falls man immer noch im grünen Bereich ist (Abbildung B), ist der Code fertig.

Erfolgreiche Tests

Auslagern und aufräumen: setUp und teardown

In diesem Beispiel wurde eine statische Methode der Klasse FormatDate getestet und es gab innerhalb der Tests keine Code-Wiederholungen. Wenn man allerdings in allen Tests wiederholt eine Klasse instanziieren muss, kann diese Wiederholung umgangen werden, indem man den sich wiederholenden Code in die Methode setUp auslagert. Das Framework ruft diese Methode automatisch auf, bevor die Tests ausgeführt werden. Die Methode teardown wird nach Beendigung aller Tests aufgerufen. Diese Methode kann man benutzen, um Ressourcen wieder freizugeben.

Das Sicherheitsnetz von TDD

Der Einsatz der richtigen Tests ist besonders sinnvoll, wenn der Code Bug-Fixes erhält oder von einem anderen Entwickler weiterbearbeitet wird. In einem solchen Fall kann man die Tests ausführen um sicherzustellen, dass durch die Änderungen am Code nichts kaputtgegangen ist, was vorher noch funktioniert hat.

Insgesamt kann man jedoch sagen, dass nach der endgültigen Absegnung des Designs und dem Beginn der Entwicklungsphase nur wenige Entwickler noch Änderungen am Design wagen. Ein Refactoring kann sicher durchgeführt werden, wenn man über einen Test-Ausrüstung verfügt, die sicherstellt, dass die Änderungen während des Refactorings nichts kaputtmachen.

Idealerweise sollte man die Test-Suite jeden Tag einmal ausführen. Wenn man jeden Tag einen grünen Balken zu sehen bekommt, ist das einem ruhigen Schlaf durchaus förderlich, weil man sicher sein kann, dass im Laufe des Tages durch die Entwicklung nichts beschädigt wurde.

Weitere Tools

Im Zuge der zunehmenden Verbreitung von TDD haben viele Entwickler festgestellt, dass JUnit nicht immer für das optimale Werkzeug darstellt, besonders in Bezug auf J2EE. Aus dieser Situation heraus sind eine Reihe von JUnit-Abkömmlingen entstanden, die das Kernkonzept von JUnit für bestimmte Anforderungen erweitern. Zu diesen zählen u. a. J2EEUnit, StrutsTestCase und Cactus.