Was ist Testgetriebene Entwicklung?

Bei der testgetriebenen Entwicklung (engl. Test-Driven Development, TDD) werden Tests dazu benutzt, um die Softwareentwicklung zu steuern. Der Ablauf dieser Programmierung ist zyklisch:

• Ein Test wird geschrieben, der zunächst fehlschlägt.
• Genau soviel Produktivcode wird implementiert, dass der Test erfolgreich durchläuft.
• Test und Produktivcode werden refaktorisiert.

Die Tests werden typischer-, aber nicht notwendigerweise, mit dem XUnit-Framework in der gleichen Sprache wie der Produktivcode implementiert. Tests, die erfolgreich durchlaufen, werden durch einen grünen, nicht erfolgreiche durch einen roten Balken dargestellt. Man spricht daher vom "Red-Green-Refactor"-Zyklus.

Testgetriebene Entwicklung geht inkrementell vor. Jeder durchlaufene TDD-Zyklus reichert die Software um neue Fähigkeiten an - und das minutiös, denn jeder Zyklusabschnitt sollte nicht länger als ein paar Minuten dauern.

Die Tests noch vor den Komponenten zu schreiben, die man eigentlich testen möchte, ist sehr markant für TDD. Dies wird als Test-First bezeichnet und darum ist TDD keine Test-, sondern eine Designstrategie. Denn wird der Test zuerst geschrieben, so wird die Schnittstelle der zu testenden Komponente bereits benutzt, bevor sie tatsächlich existiert. Der Entwickler bekommt frühestmöglich Feedback, ob das Design auch verwendbar sein wird.

Die Implementierung des produktiven Codes erfolgt erst, wenn ein Test vorliegt, der dies verlangt. Es soll dann genau soviel Code geschrieben werden, dass der Test erfolgreich durchläuft. Wird zuviel Produktivcode für einen Test geschrieben, dann entstehen nicht getestete Stellen, die beim Refactoring Probleme bereiten können.

Beim Refactoring werden die Tests und der Produktivcode gleichermaßen aufgeräumt. Ziel hierbei ist es, die Software einfach, redundanzfrei und verständlich zu gestalten. Diese Phase des TDD-Zyklus geht dem Zyklusanfang unmittelbar voraus: Um einen bestimmten Test zu schreiben kann es notwendig sein, zuerst ein Refactoring an den anderen Tests oder dem Produktivcode vorwegzunehmen.

Der Zyklus ist überschneidungsfrei, jede Aktivität beim testgetriebenen Entwickeln läßt sich einem Abschnitt zuordnen. Es sollten keine Tests in Phase 2 und 3 und kein Produktivcode in Phase 1 und 3 geschrieben werden. Beim Refactoring wird das Verhalten des Codes nicht verändert, also dabei weder bei den Tests (Phase 1) noch im Produktivcode (Phase 2) etwas funktional verändert.

Prinzipien, die TDD vereint, sind die kontinuierliche Designverbesserung, einfaches Design und Test-First. TDD selbst ist eine Kerntechnik von Extreme Programming und damit Teil der agilen Softwareentwicklung. Es verspricht Qualitätssoftware und eine deutliche Aufwertung der Softwarearchitektur dank evolutionärem Design.

wartbare Qualitätssoftware:

• kein ungetesteter Code
• saubere/testbare Architektur durch TDD als Designstrategie
• keine/wenig Redundanzen durch gnadenloses rechtzeitiges Refaktorisieren

effektive und effiziente Erstellung der Software:

• kein unnötiger Code auf Vorrat
• Konzentration auf das Wesentliche