Seite 4: Fazit

Inhaltsverzeichnis

TDD klingt aufgrund der wenigen Regeln zunächst einfach. Doch TDD ist schwierig, und im praktischen Projekteinsatz jenseits einfacher Übungsaufgaben lauern viele Fallstricke. Auch das Schreiben von Tests will gelernt sein. Zudem versperrt eine Vielzahl an Design-Problemen den Weg zum ungetrübten TDD-Vergnügen. Es fehlt also oft neben grundlegendem TDD- auch das notwendige Design-Know-how. So gibt der TDD-Neuling schnell frustriert mit dem Gefühl auf, dass TDD nicht funktioniert und es sich bei TDD-Anhängern um eine realitätsferne Gruppe von Spinnern handelt. Um dem entgegenzuwirken, hat sich der Wissenstransfer durch "pair programming" zusammen mit einem TDD-erfahrenen Entwickler bewährt: ob "on the job" mit einem Kollegen oder externem Coach oder im Rahmen privat besuchter Code Retreats und Dojos.

Hat man die steile Lernkurve allerdings durchlaufen, bringt TDD ein großes Qualitätspaket in die Entwicklerstube. Jeder Lauf der automatisierten Testsuite validiert, ob die gewünschte Funktion erfüllt ist, und erspart Entwicklern schlaflose Nächte vor dem Release. Zusätzlich zur reinen Testautomatisierung hat TDD aber weitere Qualitätsverbesserungen im Gepäck.

Der Test-first-Ansatz steigert die Testdisziplin. Er und BDD helfen, nicht benötigten Code zu vermeiden und die Anforderungen zu verbessern. Weiterhin unterstützt der TDD-Prozess dabei, die zu erledigende Aufgabe in kleine mundgerechte Häppchen zu schneiden und so den Fokus der Entwickler zu verbessern. Die Aufteilung in die drei Phasen des TDD-Zyklus führt zu einer klar definierten Aufgabe zu jedem Zeitpunkt. Die "Baby steps"-Strategie verkürzt den Zyklus und beschleunigt das Feedback. Test-Driven Design bedeutet hohe interne Codequalität.

TDD ist ein Werkzeug der Entwickler. Dass Tests und Implementierung aus einer Hand stammen, bringt zwar viele Vorteile, birgt aber auch die Gefahr der Betriebsblindheit. Hier können Tester eine weitere Perspektive einbringen. Durch Beteiligung am "specification workshop", durch ausschöpfendes, aber auch exploratives Testen können sie die automatisierten Entwicklertests optimal ergänzen.

David Völkel
arbeitet als Entwickler und Consultant für codecentric. Als begeisterter "Software Craftsman" spricht er auf Konferenzen und organisiert die Softwerkskammer-Meetups in München.

Literatur

1. Kent Beck; Test-Driven Development: By Example; Addison-Wesley 2002
2. Kent Beck, Cynthia Andres; Extreme Programming Explained: Embrace Change; Addison-Wesley 2004
3. Steve Freeman, Nat Pryce; Growing Object-Oriented Software, Guided by Tests; Addison-Wesley 2009
4. Martin Fowler; Refactoring: Improving the Design of Existing Code; Addison-Wesley 1999

(ane)