Test Driven Development

Veröffentlicht auf 22. März 2010

Test Driven Development (TDD) ist eine evolutionäre Entwicklungsmethode, die häufig zusammen mit agilen Methoden Anwendung findet. Dabei werden Tests entsprechend den Anforderungen an eine Funktion erstellt und erst im Nachhinein der funktionale Code implementiert.

Die Tests werden meist innerhalb eines Unit-Test-Frameworks implementiert und laufen gelassen. Zu Beginn werden die Tests fehlschlagen. Ziel des Entwicklers ist es, den Code so lange zu verbessern, bis alle zugehörigen Tests bestanden werden.

Kommen neue Anforderungen oder Funktionen hinzu, werden zuerst neue Tests implementiert und danach der Code erweitert. Danach werden alle Test erneut durchgeführt, solange bis wieder alle Tests bestanden werden.
Um aber nicht nach jeder Änderung ständig alle Test erneut durchführen zu müssen, kann man die sogenannte "Continuous Integration"-Methode anwenden. Hierbei wird meist zentral ein System aufgesetzt, in das neuer Code eingecheckt werden muss und dort fortlaufend Tests unterzogen wird. Ziel ist ein ständig funktionierendes System.
Als vorletzter Schritt werden unnötige Zeilen entfernt, doppelter Code extrahiert, Konventionen überprüft, Code-Metriken ausgewertet oder sonstige Optimierungsmaßnahmen durchgeführt und zuletzt erneut getestet.

Vorteile von TDD:
* Einfaches Testsendekriterium.
* Code wird fortlaufend optimiert und ist leicht zu ändern.
* Die enthaltenen Funktionen werden durch die Tests zugleich dokumentiert.
* Aktive Fehlervermeidung, Fehler werden früher entdeckt.
* Fehler sind durch Mini-Iterationen leichter lokalisierbar.
* Software wird für den Test optimiert, Stichwort: Testability.
* Leicht zu testende Software wird bevorzugt getestet und damit ausgiebiger.
* Einfach testbare Software und gutes Software-Design haben die gleichen Grundlagen. Die Software-Architektur verbessert sich in der Regel.
* Klassen und Methoden bleiben überschaubar, Schnittstellen schlichter, da sie testbar sein müssen.
* Es entsteht ein Qualitätsbewusstsein über das ganze Projekt hinweg, nicht nur bei einer kleinen Expertengruppe.
* Die spätere Testautomatisierung wird enorm vereinfacht.
* Studien zeigen einer höhere Effektivität als reine Unit-Test im Anschluss an die Entwicklung.
* Mehr Mini-Iterationen, dafür aber weniger größere Iterationen, weniger Mehrarbeit, insgesamt eine klare Kostenreduktion.

Nachteile:
* Eine konsequente Durchführung ist notwendig.
* Akzeptanzprobleme: Wie soll man was testen, was noch nicht existiert?
* Gutes Testmethodikwissen ist für eine akzeptable Testqualität und -abdeckung notwendig.
* TDD im Modultest ersetzt keine weiteren Tests, ein Systemtest etc. ist trotzdem notwendig. TDD ist kein Allheilmittel!

TDD kann auch in anderen Bereichen, wie z.B. im Systemtest eingesetzt werden, dafür werden ebenfalls erst die Testfälle spezifiziert und entsprechen den Testfällen implementiert. Die Software wird wiederum erst freigegeben, wenn alle spezifizierten Testfälle erfolgreich bestanden wurden.

Ein bekanntes Beispiel für eine auf Testbarkeit getrimmte Software mit einer Test-API, die durch TDD entstand sein soll, soll das Macro Interface von Microsoft Excel sein. Heute ein zusätzliches und wichtiges Feature von Excel.

Geschrieben von Robert Bullinger

Veröffentlicht in #Methoden und Standards

Kommentiere diesen Post