Test Driven Development in der Praxis

Flexibel auf geänderte (Business-)Anforderungen reagieren können, die Forderung nach raschen time-to-market erfüllen können, trotzdem im Umgang mit Menschen respektvoll sein und Spaß an den Erfolgen des Teams haben können! So oder so ähnlich kann man agile Entwicklung zusammenfassen. Wichtig bei all dem ist die Identifikation des gesamten Teams mit der geteilten Aufgabe der Qualitätssicherung („collective quality ownership“). Eine der mittlerweile immer interessanter werdenden Standard Methoden die hierbei zum Einsatz kommen ist Test Driven Development, kurz TDD. Hierbei geht es um das entwicklungsnahe Testen bzw. das testnahe Entwickeln. Bei dieser testgetriebenen Entwicklung erstellt der Programmierer die Tests bevor er die jeweiligen dazu gehörige Business Logik erstellt.

TDD in der Praxis - "Red, Green, Refactor"

Test Driven Development wird oft zu Unrecht als "unnötiger zusätzlicher Aufwand", sowohl bei Entwicklern als auch im Management, eingeschätzt. TDD zwingt den Entwickler vor der eigentlichen Umsetzung der Business Logik die zugehörigen Unit Tests zu schreiben - "Es darf keine Business Logik implementiert werden ohne zugehörigen, fehlschlagenden Unit Test". Zusätzlich ist eine fixe Verbesserungsphase, so genanntes "Refactoring" eingeplant, die für qualitativ hochwertige Ergebnisse sorgen soll. Diese drei Phasen der Entwicklung - Unit Test schreiben, Business Logik umsetzen, Code verbessern - werden iterativ bis zur fertigen Lösung fortgesetzt.

Das führt im ersten Blick zu mehr Aufwand, aber auch nur aus dem Grund, dass Unit Tests im Allgemeinen viel zu wenig Aufmerksamkeit in der Vergangenheit bekommen haben. Aber TDD geht noch viel weiter als einfach nur die Testfälle vor der Business Logik zu schreiben: TDD ist eine Methode, die den Fokus auf qualitativ hochwertige Ergebnisse legt! Naming, Duplication und ein gutes Design sind nur einige wichtige Punkte, die in TDD groß geschrieben werden.

Die Vorteile von TDD

Ein Vorteil liegt auf der Hand: Durch den Einsatz von TDD erreicht man eine theoretische Code Coverage der Business Logik von 100%. Oben drauf bekommt man mit dem Fokus auf Naming und Design einen auf Lange Sicht wartbaren Code. Die Entwickler können durch das dicht gewebte Sicherheitsnetz der Unit Tests ohne Gefahr große Teile der Business Logik bei Bedarf neu erstellen, denn: Die Anforderungen an die Business Logik sind in den Unit Tests persistiert und die korrekte Umsetzung kann laufend sichergestellt werden.

Ein weiterer und nicht unwesentlicher Vorteil wird durch TDD erreicht: die Entwickler sollen wieder zufrieden und stolz auf deren Machwerk blicken können. Software Craftsmanship wird groß geschrieben, weg von Programmiermaschinen. Und zufriedene Arbeiter leisten doch zu meist auch gute Arbeit.