Test Driven Development: So funktioniert die Methode

Mit steigender Komplexität von Computerprogrammen werden auch die agilen Methoden des Test Driven Developments (TDD) immer beliebter. Und das aus gutem Grund: Mit TDD sorgen Programmierer dafür, dass das Design einer Software auch gut durchdacht ist, bevor sie sich ans Schreiben des Funktionscodes machen. Diese Vorgehensweise erhöht nicht nur die Qualität der Software maßgeblich, sondern reduziert auch den Wartungsaufwand.

Die testgetriebene Entwicklung kommt u. a. im Extreme Programming zum Einsatz, das sich durch fortlaufende Reviews, Tests, Design und Redesign auszeichnet. Auch das Test Driven Development hält sich an einen Entwicklungszyklus, dessen Reihenfolge für eine effektive Umsetzung eingehalten werden muss.

Verschiedene Testmethoden, die die Qualität einer Software kontrollieren, gibt es schon lange. Bereits zu Beginn der Software-Entwicklung überprüften unabhängige Tester Computerprogramme im Qualitätsmanagement auf ihre Funktionalität. Die eigentliche Entwicklung der Software und die Testverfahren wurden damals noch als unabhängige Prozesse angesehen. Erst mit dem US-amerikanischen Software-Entwickler und Begründer des Extreme Programmings Kent Beck entstand der Test-First-Ansatz. Dieser hat den bisherigen Ablauf einfach umgekehrt: Anstatt erst den Quellcode zu schreiben und diesen dann zu testen, schreibt das Entwicklerteam erst die Tests. Dann verwendet es die Testfälle, um den bestmöglichen Code zu schreiben und zu implementieren.

Auch wenn die testgetriebene Entwicklung einem Laien zunächst kontraintuitiv erscheint, hat sie durchaus ihren Sinn und führt zu besseren Ergebnissen. Während bei herkömmlichen, nachgeschalteten Testverfahren ein Wasserfallmodell oder V-Modell eingesetzt wird, verlaufen die Prozesse beim TDD nämlich in einem Zyklus. Das heißt, dass Sie zuerst Testfälle bestimmen, die häufig fehlschlagen. Dies geschieht mit Absicht, denn im zweiten Schritt verfassen Sie nur so viel Code, wie für das Bestehen der Tests benötigt wird. Daraufhin werden die Komponenten refaktorisiert: Unter Beibehaltung seiner Funktionen erweitern Sie den Quellcode oder strukturieren ihn falls nötig um.

Das Test Driven Development orientiert sich an den Ergebnissen der von Ihnen bestimmten Testfälle. Die zyklische Verfahrensweise stellt sicher, dass der Code erst ins Produktivsystem übertragen wird, wenn alle Anforderungen an die Software erfüllt sind. Das heißt, dass Sie die Codebestandteile so oft refaktorisieren und neu testen, bis der Test nicht mehr als fehlerhaft angezeigt wird. Durch diese Methode reichern Sie die Software schrittweise mit neuen Funktionen an, da Sie nach jedem bestandenen Test einen neuen Quellcode verfassen. Aus diesem Grund zählt TDD auch zu den inkrementellen Vorgehensmodellen in der Software-Entwicklung.

Einzelne Testfälle durchlaufen den Zyklus in der Regel nicht länger als ein paar Sekunden oder Minuten. So machen sich die Resultate schnell im Produktivcode bemerkbar. Damit die Iteration ohne zusätzlichen Aufwand geschieht, brauchen Sie ein TDD-Werkzeug und -Framework. Typischerweise verwenden Entwickler ein Tool zur Build-Automatisierung wie CruiseControl oder Jenkins. Diese erlauben die kontinuierliche und fehlerfreie Integration von Komponenten in den Quellcode. Beliebt bei der Java-Entwicklung sind auch JUnit, Maven oder Ant. Generell gilt: Die Tests werden immer in der gleichen Sprache wie der Funktionscode geschrieben. Für PHP gibt es u. a. die Werkzeuge Ceedling oder CMock.

Aber wie läuft das Testverfahren genau ab? Der Zyklus, dem Programmierer im Test Driven Development folgen, wird auch Red-Green-Refactor-Zyklus genannt. Dieser beschreibt die einzelnen Phasen, die Sie für maximale Effizienz durchlaufen:

1. Rote Phase: In dieser Phase denken Sie sich in die Rolle des Nutzers hinein. Dieser möchte den Code auf einfache Weise verwenden. Sie schreiben also einen Test, der Komponenten enthält, die noch nicht implementiert wurden. So müssen Sie eine Entscheidung darüber treffen, welche Elemente für das Funktionieren eines Codes wirklich notwendig sind.
2. Grüne Phase: Angenommen, der Test schlägt fehl und wird rot markiert. Nun nehmen Sie die Rolle eines Programmierers ein, der versucht, eine simple Lösung zu finden. Wichtig: Sie schreiben nur so viel Code wie nötig. Diesen integrieren Sie in den Produktivcode, sodass der Test mit grün markiert wird.
3. Refactoring: In diesem Schritt wird der Produktivcode regelrecht „aufgeräumt“ und in seiner Struktur perfektioniert. Das heißt, Sie sollten ihn ergänzen und so umstrukturieren, dass er aus Entwicklersicht elegant und verständlich ist. Entfernen Sie z. B. Code-Duplizierungen und bringen Sie ihn so auf ein professionelles Niveau.

Achten Sie darauf, dass sich die einzelnen Aktivitäten nicht überschneiden. Das heißt, dass Sie keine Tests in Phase 2 oder 3 und keinen Produktivcode in Phase 1 und 3 schreiben. Im folgenden Video sehen Sie, wie die testgetriebene Entwicklung in der Praxis funktioniert:

Test Driven Development ist eine Designstrategie, die den Entwicklungsprozess einer Software mittels verschiedener Tests leitet. Im Gegensatz zu nachgestellten Verfahren sind die Testfälle im TDD von Anfang an Teil des Software-Designs. Dabei unterscheiden sich die Tests, die im Rahmen von TDD eingesetzt werden, in Zweck und Umfang. Der einfachste Test ist der Modultest oder Unit-Test. Mit diesem werden einzelne Komponenten eines Computerprogramms getestet. Komplexer sind die Integrations- und Funktionstests, mit denen Sie das Zusammenspiel verschiedener Systemteile und die Gesamtfunktionalität einer Software überprüfen.

Aus dem TDD entwickelte sich vor einigen Jahren das Behavior Driven Development (BDD), auch verhaltensgetriebene Software-Entwicklung genannt. Bei dieser konzentriert sich ein Entwicklerteam zunächst nicht auf die Richtigkeit des Codes, sondern auf die gewünschte Verhaltensweise der Software. Der Vorteil ist hier, dass Sie für das Schreiben der Testfälle kein technisches Codeverständnis haben müssen und so Stakeholder und Qualitätsmanager in die Entwicklung miteinbinden können. Generell lässt sich sagen, dass BDD die beste Vorgehensweise beim Schreiben von Tests festlegt, während TDD für eine saubere Architektur sorgt.

In der folgenden Tabelle sind die Vor- und Nachteile der testgetriebenen Entwicklung kurz zusammengefasst:

Obwohl Sie die verschiedenen Testverfahren auch einzeln anwenden können, erhalten Sie mit einer Kombination aus test- und verhaltensgetriebenen Entwicklungsmethoden eine hochwertigere Software. Diese bereitet auch dem Endnutzer mehr Freude.