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

Trotz der hohen Bedeutung, die der Erstellung fehlerfreier Software beigemessen wird, wendet man eine Menge Zeit für das nachträgliche Entfernen von Bugs auf, statt diese von vornherein zu vermeiden. Beim Unit-Testing testen die meisten Entwickler ihre Arbeit erst, nachdem sie abgeschlossen ist, und nicht bereits in der Entwicklungsphase. Dafür kann ihnen niemand einen Vorwurf machen, da enge Projekttermine oft nur wenig Zeit für das Programmieren vorsehen. Dies liegt daran, dass die Projektverantwortlichen häufig überzeugt sind, ein Super-Design in Händen zu haben, das ganz einfach umzusetzen ist. Leider sieht die Realität oft anders aus.

Die testgetriebene Alternative

Testgetriebene Entwicklung (TDD = Test-Driven-Development) bietet hier einen neuen Ansatz. Dieses Konzept betrachtet das Testen als kontinuierlichen Prozess, der als integraler Bestandteil während der Entwicklung von Programmcode ausgeführt wird. TDD befasst sich mit Unit-Tests, die vom Entwickler geschrieben wurden, um sicherzustellen, dass sein Code wie vorgesehen funktioniert und auch dauerhaft funktional bleibt. Dabei geht es vor allem darum, wie man an die ganze Sache herangeht, und nicht um irgendwelche Spezialtools. TDD beschränkt sich gewiss nicht auf Java, denn das Konzept ist für alle anderen Programmiersprachen genau so relevant. Allerdings ist TDD in der Java-Welt besonders populär, deshalb wird es in diesem Artikel nur um Java gehen.

Ein fundamentaler Unterschied zwischen TDD und der normalen Methode des Erstellens von Testplänen vor dem Beginn der Entwicklung besteht darin, dass mit TDD die Tests nicht irgendwo als Word- oder Excel-Dokument vergessen in der Schublade liegen. Wenn man zum Beispiel eine Java-Klasse mit einer komplexen Logik entwickelt, existieren mit TDD die Tests auch als ordentlicher Java-Code und der Entwickler ist für das Schreiben der Tests selbst verantwortlich. Entwickler murren häufig, wenn sie mit Word oder Excel arbeiten müssen, doch bei den Testfällen in Java dürfte selbst der unwilligste Programmierer keine Probleme beim Schreiben der Tests haben.

Kent Beck beschreibt in seinem Buch Test-Driven-Development: By Example den TDD-Zyklus, der aus den folgenden Schritten besteht:

• Einen kleinen Test entwerfen.
• Alle Tests durchführen und einen Fehler finden.
• Eine kleine Änderung vornehmen.
• Alle Tests erfolgreich durchführen.
• Refactoring, um Duplikate zu vermeiden.

Ein Beispiel

Um dies zu demonstrieren, soll hier ein Blick auf ein Stück einfachen Codes geworfen werden, der einen Daten-String als Eingabe erhält, ihn wie vorgesehen formatiert und als ordentlich formatierten String wieder ausgibt. Dabei soll dem oben beschriebenen Entwicklungszyklus gefolgt werden.

Für dieses Beispiel wird die Test-Umgebung JUnit eingesetzt. JUnit unterstützt die Entwickler bei der Durchführung selbst geschriebener Tests sowie bei einigen einfachen Vergleichen. Dazu muss man lediglich beim Schreiben der Tests einige Regeln befolgen.

Die zu programmierende Methode soll die folgenden Strings als Eingabe erhalten können:

• null
• MM-TT-JJJJ
• MM-T-JJJJ
• M-TT-JJJJ
• MM-TT-JJ

Für all diese Varianten soll ein String im Format MM-TT-JJJJ ausgegeben werden bzw. ein Leerstring, wenn die Eingabe null ist. Dazu wird eine einstellige Datumsangabe (Tag oder Monat) um eine 0 bzw. eine zweistellige Jahreszahl um eine 20 ergänzt. Damit steht fest, was der Code tun soll. Nun zu Schritt 1 – dem Schreiben eines Tests.

Voraussetzungen

FormatDate ist der Name der Klasse und formatDate die statische Methode, die getestet werden sollen.

Da das JUnit-Framework verwendet wird, muss man einige von dessen Vorgaben einhalten. Wie Listing A zeigt, muss die Klasse FormatDate, welche die Tests enthält, die Klasse TestCase erweitern und einige Klassen aus dem Package junit.framework.* importieren.