Testgetriebene Entwicklung

aus Wikipedia, der freien Enzyklopädie

Als testgetriebene Entwicklung (auch testgesteuerte Programmierung, engl. test first development oder test-driven development, Abkürzung TDD, manchmal auch scherzhaft Extreme Testing) bezeichnet man eine Agile Methode zur Entwicklung eines Computerprogramms, bei der die Programmierer Software-Tests vor den zu testenden Komponenten entwickeln. Unit-Tests der testgetriebenen Entwicklung sind Grey-Box-Tests statt White-Box-Tests. Die wohl bekannteste Agile Methode ist die des Extreme Programming.

Klassischerweise werden Tests nach oder parallel unabhängig zum zu testenden System entwickelt. Dies kann unter Umständen dazu führen, dass nicht die gewünschte bzw. erforderliche Testabdeckung erzielt wird. Mögliche Gründe dafür sind unter anderem:

• Akuter Zeitmangel
• Mangelhafte Testbarkeit (das zu testende System besitzt Eigenschaften, die das Testen erschweren)
• Faulheit bzw. mangelnde Disziplin der Programmierer
• Firmenpolitik verbietet Investition in nicht-funktionale Programmteile

Ein weiterer Nachteil klassischer Unit-Tests als White-Box-Tests ist, dass der Entwickler das zu testende System und seine Eigenheiten kennt und dadurch eventuell ungewollt "um Fehler herum" testet.

Die testgetriebene Entwicklung ist ein Ansatz, den Gründen für eine nicht ausreichende Testabdeckung und einigen Nachteilen der White-Box-Tests entgegenzuwirken.

Inhaltsverzeichnis 1 Vorgehensweise 2 Einsatzgebiete 3 Umsetzung 4 Kritische Betrachtung 5 Weblinks 6 Literatur

[Bearbeiten] Vorgehensweise

Die Vorgehensweise unterscheidet sich zwischen dem Testen im Kleinen (Unit-Test, White-Box-Test) und dem Testen im Großen (System-Test, Black-Box-Test, Akzeptanztest).

Bei Unit-Tests werden Test-Gerüst und Unit-Gerüst parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, besteht aus drei Hauptschritten:

1. Schreibe einen kleinen Test für den nächsten zu implementierenden Funktionalitätshappen. Dieser Test sollte nicht funktionieren.
2. Erfülle den Test mit möglichst wenig Code, um schnell wieder zum "grünen Balken" (alle Tests laufen) zurückzukehren.
3. Räume den Code auf, dazu gehört die Entfernung von Duplikation, Einführung von notwendigen Abstraktionen und Umsetzen der Codekonventionen. Ziel dieses Aufräumens ist die einfache Form des Codes.

Diese Schritte werden solange wiederholt, bis dem Entwickler keine sinnvollen Tests mehr einfallen, die fehlschlagen würden und damit die Unit für den Augenblick fertig ist. Die konsequente Umsetzung dieses Vorgehens führt zu evolutionärem Design, einem Entwurfsstil, der die ständige Weiterentwicklung eines Systems in den Vordergrund rückt.

Weil der einzelne Unit Test sowohl Eigenschaften eines White-Box-Tests als auch eines Black-Box-Tests aufweist, wird er als Grey-Box-Test bezeichnet.

Bei System-Tests werden die System-Tests vor dem eigentlichen System entwickelt oder zumindest spezifiziert. Aufgabe des Systems ist bei testgetriebener Entwicklung nicht mehr, schriftlich formulierte Anforderungen, sondern spezifizierte System-Tests zu erfüllen.

In beiden Fällen wird großer Wert auf eine möglichst vollständige Testautomatisierung gelegt. Für testgetriebene Entwicklung ist es erforderlich, dass sämtliche Tests einfach ("per Knopfdruck") und möglichst schnell ausgeführt werden können. Für Unit-Tests bedeutet das wenige Sekunden, für Systemtests meist maximal einige Minuten.

Neben dem Entgegenwirken einiger Nachteile des klassischen "Hinterher"-Testens besitzt die testgetriebene Entwicklung noch einige weitere Vorteile.

Nennenswerte Vorteile sind:

• Die Erfüllung der Anforderungen wird eine leicht messbare Metrik.
• Die Unit-Tests sind Grey-Box-Tests statt White-Box-Tests.
• Die Durchführung von Refaktorisierungen ist mit weniger Fehlern behaftet (im Idealfall fehlerfrei).
• Die einfache, schnelle Ausführung von Tests ermöglicht es den Programmierern, die meiste Zeit an einem korrekten System zu arbeiten.
• Die Unit-Testsuite stellt eine Art ausführbare Spezifikation dar. Das heisst, dass durch die Testsuite eindeutig definiert ist, was das Softwaresystem zu leisten hat. Somit dient eine Testsuite auch zu Dokumentationszwecken.

[Bearbeiten] Einsatzgebiete

Die testgetriebene Entwicklung ist fester Bestandteil des Extreme Programming (XP) und anderer agiler Methoden. Auch außerhalb von XP ist sie häufig in Verbindung mit Paarprogrammierung anzutreffen.

[Bearbeiten] Umsetzung

Die wesentlichen Bestandteile der Umsetzung sind:

• Framework zur Testentwicklung
• Framework zur Testautomatisierung
• Framework zur Build-Automatisierung, z.B. CruiseControl

In Java kommen dafür meist JUnit und Ant zum Einsatz. Für die meisten anderen Programmiersprachen existieren ähnliche Werkzeuge, wie z.B. für PHP die PEAR-Erweiterung PHPUnit.

Bei der Entwicklung komplexer Systeme in denen mehrere Komponenten zusammenarbeiten müssen, die unabhängig voneinander entwickelt werden z.B. die Entwicklung einer Geschäftsanwendung die eine Datenbank als Persistenzmedium verwendet, werden Mock-Objekte verwendet, um einzelne Komponenten wie z. B. die Datenbankzugriffe ohne die notwendige Existenz einer Datenbank testen zu können. Das Mock Objekt simuliert in dem Fall das Verhalten einer Datenbank mit einer festgelegten Verhaltensweise.

Die testgetriebene Umsetzung von Akzeptanztests und Systemtests wird beispielsweise durch FIT (Framework for Integrated Tests)] möglich. Eine populäre FIT-Variante stellt Fitnesse dar, ein Wiki-Server mit integrierter Testerstellung- und Testausführungsumgebung.

[Bearbeiten] Kritische Betrachtung

Programmierern, die noch keine Erfahrung in der testgetriebenen Entwicklung besitzen, finden die Umsetzung manchmal schwierig oder gar unmöglich. Sie fragen sich, wie man etwas testen soll, das noch nicht vorhanden ist. Das kann dazu führen, dass sie die testgetriebene Entwicklung vernachlässigen, was insbesondere bei agilen Methoden wie dem Extreme Programming Schwierigkeiten oder sogar den Zusammenbruch des Entwicklungsprozesses auslösen kann. Ohne ausreichende Unit-Tests wird keine ausreichende Testabdeckung für z.B. Refaktorisierungen und die gewünschte Qualität erreicht. Dem kann man mit Paarprogrammierung und Schulung entgegenwirken.

Des weiteren ist zu beachten, dass auch diese stark kontrollierende Art der Programmierung nicht jeden Fehler aufdecken kann. Insbesondere Fehler, die durch programmexterne Quellen erzeugt werden, beispielsweise Timingfehler wie Thread-Deadlocks oder RS232-Kommunikation, oder wenn nicht alle potentiellen Eingaben einer Funktion getestet werden können, beispielsweise die grafische Darstellung von großen Datenmengen: hier kann nicht jede mögliche Kombination von Daten getestet werden und das visuelle Ergebnis ist nur schwer vom Programm testbar.

[Bearbeiten] Weblinks

• JUnit, Framework zur testgetriebenen Entwicklung in Java (Englisch)
• TDD Community (Englisch)
• Einführende Artikel
• Bessere Codequalität und Kosteneinsparungen durch Unit-Tests / Modultests
• Eine kurze Einführung in die Prinzipien der Testgesteuerten Programmierung
• Fitnesse
• Framework for Integrated Tests

[Bearbeiten] Literatur

• Kent Beck: Test Driven Development by Example, Addison-Wesley Verlag, ISBN 0321146530
• Johannes Link: Softwaretests mit JUnit - Techniken der testgetriebenen Entwicklung, ISBN 3898643255
• Frank Westphal: Testgetriebene Entwicklung mit JUnit und FIT, ISBN 3898642208
• Klaus Meffert: JUnit Profi-Tipps - Software erfolgreich testen, ISBN 3935042760