Testgetriebene Entwicklung
Testgetriebene Entwicklung (auch testgesteuerte Programmierung; englisch test first development oder test-driven development, TDD) ist eine Methode, die häufig bei der agilen Entwicklung von Computerprogrammen eingesetzt wird. Bei der testgetriebenen Entwicklung erstellt der Programmierer Softwaretests konsequent vor den zu testenden Komponenten.
Gründe für die Einführung einer testgetriebenen Entwicklung
Nach klassischer Vorgehensweise, beispielsweise nach dem Wasserfall- oder dem V-Modell, werden Tests parallel zum und unabhängig vom zu testenden System entwickelt oder sogar nach ihm. Dies führt oft dazu, dass nicht die gewünschte und erforderliche Testabdeckung erzielt wird. Mögliche Gründe dafür sind unter anderem:
- Fehlende oder mangelnde Testbarkeit des Systems (monolithisch, Nutzung von Fremdkomponenten, …).
- Verbot der Investition in nicht-funktionale Programmteile seitens der Unternehmensführung. („Arbeit, von der man später im Programm nichts sieht, ist vergeudet.“)
- Erstellung von Tests unter Zeitdruck.
- Nachlässigkeit und mangelnde Disziplin der Programmierer bei der Testerstellung.
Ein weiterer Nachteil klassischer White-Box-Tests ist, dass der Entwickler das zu testende System und seine Eigenheiten selbst kennt und dadurch aus Betriebsblindheit unversehens „um Fehler herum“ testet.
Die Methode der testgetriebenen Entwicklung versucht den Gründen für eine nicht ausreichende Testabdeckung und einigen Nachteilen der White-Box-Tests entgegenzuwirken.
Vorgehensweise
Bei der testgetriebenen Entwicklung ist zwischen dem Testen im Kleinen (Unit-Tests)/ Komponententests und dem Testen im Großen (Integrationstests, Systemtests, Akzeptanztests) zu unterscheiden, wobei Becks Methode auf Unit-Tests ausgelegt ist.
tests first
Unit-Tests werden vor dem eigentlichen Computerprogramm geschrieben. Es ist nicht festgelegt, ob der Programmierer, der die Implementierung vornehmen wird, auch die Unit-Tests erstellt. Es ist erlaubt, dass mehrere fehlschlagende Unit-Tests gleichzeitig existieren. Die Umsetzung des von einem Unit-Test geforderten Verhaltens im Computerprogramm kann zeitlich verschoben werden.
Die Methode tests first kann als Vorstufe der testgetriebenen Entwicklung betrachtet werden.
TDD nach Kent Beck
Unit-Tests und mit ihnen getestete Units werden stets parallel entwickelt. Die eigentliche Programmierung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile, die man im englischen Red-Green-Refactor nennt
- Red: Schreibe einen Test, der ein neues zu programmierendes Verhalten (Funktionalität) prüfen soll. Dabei fängt man mit dem einfachsten Beispiel an. Ist die Funktion schon älter, kann dies auch ein bekannter Fehler oder eine neu zu implementierende Funktionalität sein. Dieser Test wird vom vorhandenen Programmcode erst einmal nicht erfüllt, muss also fehlschlagen.
- Green: Ändere den Programmcode mit möglichst wenig Aufwand ab und ergänze ihn, bis er nach dem anschließend angestoßenen Testdurchlauf alle Tests besteht.
- Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Code-Duplizierung), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus etc. In dieser Phase darf kein neues Verhalten – das ja dann nicht durch Tests schon abgedeckt wäre – eingeführt werden. Nach jeder Änderung werden die Tests ausgeführt, ihr Fehlschlag verbietet es, die offenbar fehlerhafte Änderung schon in den genutzten Code zu übernehmen. Ziel des Aufräumens ist es, den Code schlicht und verständlich zu machen.
Diese drei Schritte werden so lange wiederholt, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler keine sinnvollen weiteren Tests mehr einfallen, welche vielleicht noch scheitern könnten. Die so behandelte programmtechnische Einheit (Unit) wird dann als einstweilen fertig angesehen. Die gemeinsam mit ihr geschaffenen Tests werden beibehalten, damit auch nach künftigen Änderungen wiederum daraufhin getestet werden kann, ob die schon erreichten Aspekte des Verhaltens weiterhin erfüllt werden.
Damit die – auch Transformationen genannten – Änderungen in Schritt 2 zum Ziel führen, muss jede Änderung zu einer allgemeineren Lösung führen; sie darf also nicht etwa nur den aktuellen Testfall auf Kosten anderer behandeln. Tests, die immer mehr ins Einzelne gehen, treiben den Code so zu einer immer allgemeineren Lösung. Die Beachtung der Transformationsprioritäten führt dabei regelmäßig zu effizienteren Algorithmen.[1]
Die konsequente Befolgung dieser Vorgehensweise ist eine evolutionäre Entwurfsmethode, indem jede der einzelnen Änderungen das System weiterentwickelt.
Das Kernproblem: Aufwand-Einwand und Gegeneinwände
Haupteinwand gegen das beschriebene Vorgehen ist der vermeintlich hohe Aufwand.
Die beschriebene Idee macht sich aber zunutze, dass der gedankliche Aufwand, der beim Programmieren in die konstruktive Beschreibung, also das Programm, investiert wird, und den Hauptteil der Programmierzeit ausmacht (im Verhältnis zum Tippaufwand etwa), eine Aufzählung einzelner zu erfüllender Punkte und Fälle beinhaltet. Mit nur wenig mehr Aufwand lässt sich also genau zu diesem Zeitpunkt vor der Programmierung der abzudeckende Fall beschreiben, das vorherige Schreiben weniger Testzeilen kann sogar zu einer besseren gedanklichen Strukturierung und höherer Codequalität führen. Zweitens führt die testgetriebene Entwicklung zu einer bestimmten Disziplin, welche Funktionen in welcher Reihenfolge implementiert werden, weil man sich erst einen Testfall überlegen muss, und damit potentiell zu einer höheren Berücksichtigung des Kundennutzens, siehe auch YAGNI.
Unit-Tests oder automatisierte Tests allgemein werden oftmals als das Sicherheitsnetz eines Programms bei notwendigen Änderungen beschrieben, ohne eine hohe Testabdeckung ist ein Softwaresystem grundsätzlich anfälliger für Fehler und Probleme in der Weiterentwicklung und Wartung.[2]
Schon bei der ersten Erstellung kann der Aufwand mit TDD bei ein wenig Übung zu der Erfüllung einer bestimmten Funktionalität also unter dem Aufwand einer vermeintlich schnellen Lösung ohne automatisierte Tests liegen. Dies gilt nach übereinstimmender Ansicht umso mehr, je langlebiger das System ist und damit wiederholt Änderungen unterliegt. Der Aufwand, automatisierte Tests nachträglich zu schreiben, ist wesentlich höher, weil gedanklich die einzelnen Anforderungen und Programmzeilen noch einmal analysiert werden müssen, und eine vergleichbare Testabdeckung wie bei TDD ist alleine aus Aufwands- und Kostengründen dann kaum noch realistisch.
Testgetriebene Entwicklung mit Systemtests
Systemtests werden immer vor dem System selbst entwickelt oder doch wenigstens spezifiziert. Aufgabe der Systementwicklung ist bei testgetriebener Entwicklung nicht mehr, wie klassisch, schriftlich formulierte Anforderungen zu erfüllen, sondern spezifizierte Systemtests zu bestehen.
Testgetriebene Entwicklung mit Akzeptanztests
Akzeptanztestgetriebene Entwicklung (ATDD) ist zwar mit testgetriebener Entwicklung verwandt, unterscheidet sich jedoch in der Vorgehensweise von testgetriebener Entwicklung.[3] Akzeptanztestgetriebene Entwicklung ist ein Kommunikationswerkzeug zwischen dem Kunden bzw. den Anwendern, den Entwicklern und den Testern, welches sicherstellen soll, dass die Anforderungen gut beschrieben sind. Akzeptanztestgetriebene Entwicklung verlangt keine Automatisierung der Testfälle, wenngleich diese fürs Regressionstesten hilfreich wäre. Die Tests bei akzeptanztestgetriebener Entwicklung müssen dafür auch für Nicht-Entwickler lesbar sein. Die Tests der testgetriebenen Entwicklung können in vielen Fällen aus den Tests der akzeptanztestgetriebenen Entwicklung abgeleitet werden.
Gemeinsamkeiten von testgetriebener Entwicklung mit Systemtests und Unit-Tests
Bei beiden Arten von Tests wird eine möglichst vollständige Testautomatisierung angestrebt. Für testgetriebene Entwicklung müssen alle Tests einfach („per Knopfdruck“) und möglichst schnell ausgeführt werden können. Für Unit-Tests bedeutet das eine Dauer von wenigen Sekunden, für Systemtests von maximal einigen Minuten, bzw. nur in Ausnahmen länger.
Die großen Vorzüge der testgetriebenen Methodik gegenüber der klassischen sind:
- Man hat eine boolesche Metrik für die Erfüllung der Anforderungen: die Tests werden bestanden oder nicht.
- Das Refactoring, also das Aufräumen im Code, führt zu weniger Fehlern; weil man dabei in kleinen Schritten vorgeht und stets entlang bestandener Tests, entstehen dabei wenige neue Fehler, und sie sind besser lokalisierbar.
- Weil einfach und ohne großen Zeitaufwand getestet werden kann, arbeiten die Programmierer die meiste Zeit an einem korrekten System und also mit Zutrauen und konzentriert auf die aktuelle Teilaufgabe hin. (Keine „Durchquerung der Wüste“, kein „Alles hängt mit allem zusammen“)
- Der Bestand an Unit-Tests dokumentiert das System zugleich. Man erzeugt nämlich zugleich eine „ausführbare Spezifikation“ – was das Softwaresystem leisten soll, liegt in Form sowohl lesbarer wie auch jederzeit lauffähiger Tests vor.
- Ein testgetriebenes Vorgehen führt in der Tendenz zu Programmcode, der stärker modularisiert ist sowie leichter zu ändern und zu erweitern. Das geplante System wird in kleinen Arbeitsschritten entwickelt, die unabhängig geschrieben und getestet und erst danach integriert werden. Die korrespondierenden Softwareeinheiten (Klassen, Module, …) werden so kleiner, spezifischer, ihre Kopplung wird lockerer und ihre Schnittstellen werden schlichter. Nutzt man auch Mock-Objekte, zwingt dies ebenfalls dazu, Abhängigkeiten zu vermindern oder einfach zu halten, weil sonst der dabei essentielle schnelle und umstandslose Austausch von Modulen für Test- und für Produktionscode nicht möglich wäre.
- Empirische Studien konnten eine geringere Defektrate durch TDD bei unerfahrenen Entwicklern nachweisen. Dem steht allerdings auch ein höherer Zeitaufwand gegenüber. Andere empirische Studien konnten keinen Qualitätsgewinn ermitteln. Insgesamt ergibt sich so ein uneinheitliches Bild über den tatsächlichen Qualitätsgewinn allein durch TDD.[4]
Einsatzgebiete
Testgetriebene Entwicklung ist wesentlicher Bestandteil des Extreme Programming (XP) und anderer agiler Methoden. Auch außerhalb dieser ist sie anzutreffen, häufig in Verbindung mit der Paarprogrammierung. Als Übungsmethode werden oft Katas eingesetzt.
Werkzeuge
Die testgetriebene Entwicklung braucht vordringlich
- ein Werkzeug zur Build-Automatisierung wie etwa CruiseControl oder Jenkins
- einen Rahmen und ein Werkzeug zu Testentwicklung und -automatisierung,
damit die Iterationen schnell und unkompliziert durchlaufen werden können.
Bei der Java-Entwicklung kommen dafür meist Ant, Maven oder Gradle und JUnit zum Einsatz. Für die meisten anderen Programmiersprachen existieren ähnliche Werkzeuge, wie z. B. für PHP PHPUnit oder Ceedling, Unity und CMock für C[5] .
Für komplexe Systeme müssen mehrere Teilkomponenten unabhängig voneinander entwickelt werden und es finden dazu auch noch Fremdkomponenten Verwendung, etwa ein Datenbanksystem zwecks persistenter Datenhaltung. Die korrekte Zusammenarbeit und Funktion der Komponenten im System muss dann auch getestet werden. Um nun die Einzelkomponenten dabei separat testen zu können, die doch aber zu ihrer korrekten Funktion wesentlich von anderen Komponenten abhängen, verwendet man Mock-Objekte als deren Stellvertreter. Die Mock-Objekte ersetzen und simulieren im Test die benötigten anderen Komponenten in einer Weise, die der Tester ihnen einprogrammiert.
Ein Werkzeug für Akzeptanztests und Systemtests ist beispielsweise Framework for Integrated Test. Eine beliebte FIT-Variante ist Fitnesse, ein Wiki-Server mit integrierter Testerstellungs- und Testausführungsumgebung.
Kritik
Konsequenz ist nötig
Auch die Methode der testgetriebenen Entwicklung kann falsch eingesetzt werden und dann scheitern. Programmierern, die noch keine Erfahrung dabei besitzen, erscheint sie manchmal schwierig oder gar unmöglich. Sie fragen sich, wie man etwas testen soll, das doch noch gar nicht vorhanden ist. Auswirkung kann sein, dass sie die Prinzipien dieser Methode vernachlässigen, was insbesondere bei agilen Methoden wie dem Extreme Programming Schwierigkeiten beim Entwicklungsprozess oder sogar dessen Zusammenbruch zur Folge haben kann. Ohne ausreichende Unit-Tests wird keine ausreichende Testabdeckung für das Refactoring und die gewünschte Qualität erreicht. Dem kann man mit Paarprogrammierung und Schulung entgegenwirken.
Ausbildung/Übung erforderlich
Ein wesentliches Argument von Gegnern der testgetriebenen Entwicklung ist, dass insbesondere Unit-Tests den Aufwand bei Änderungen an bestehender Funktionalität unnötig erhöhen, weil eine Änderung am Produktions-Code unverhältnismäßig viele Unit-Tests fehl schlagen lässt. Die Ursache dafür liegt jedoch in der Regel darin, dass die getestete Unit nicht ausreichend separiert wurde, die Tests also nicht atomar sind.
Um dieses Problem zu vermeiden ist es notwendig, dass die Programmierer darin geschult werden, wie sie die Anforderungen in atomare Funktionseinheiten zerlegen können und dies üben.
Kein Ersatz für alle anderen Testarten
Auch diese stark auf Tests setzende Art der Programmierung kann wie alle Testarten nicht jeden Fehler aufdecken:
- Fehler, die im Zusammenspiel zwischen verschiedenen Programmen oder Programmteilen entstehen, können mittels Integrationstests eher gefunden werden als mittels testgetriebener Entwicklung
- Die Gebrauchstauglichkeit einer Software kann mittels testgetriebener Entwicklung nicht festgestellt werden. Dafür sind Usability-Tests besser geeignet.
- Die Entsprechung der Software gegenüber den funktionalen und nicht-funktionalen Anforderungen kann mittels testgetriebener Entwicklung oft nicht festgestellt werden. Dafür sind akzeptanztestgetriebene Entwicklung wie beispielsweise Behavior Driven Development oder Systemtests anzuraten.
Keine der genannten Testarten und Vorgehensweisen kann alle Fehler aufdecken, darum sollten in den meisten Fällen mehrere Testarten und fehlervermeidende Vorgehensweisen angewendet werden.
Literatur
- Kent Beck: Test Driven Development by Example. Addison-Wesley Verlag, ISBN 0-321-14653-0.
- Steve Freeman, Nat Pryce: Growing Object-Oriented Software Guided by Tests. ISBN 978-0-321-50362-6.
- James W. Grenning: Test-Driven Development for Embedded C. O'Reilly UK Ltd., 2011, ISBN 1-934356-62-X.
- Lasse Koskela: Test driven: TDD and Acceptance TDD for Java developers. ISBN 1-932394-85-0.
- Johannes Link: Softwaretests mit JUnit – Techniken der testgetriebenen Entwicklung. ISBN 3-89864-325-5.
- Frank Westphal: Testgetriebene Entwicklung mit JUnit und FIT. dpunkt, 2005, ISBN 3-89864-220-8 (online [PDF]).
Weblinks
- JUnit, Framework zur testgetriebenen Entwicklung in Java (englisch)
- Einführender Artikel
- Bessere Codequalität und Kosteneinsparungen durch Einheittests/Modultests
- Eine kurze Einführung in die Prinzipien der Test gesteuerten Programmierung
- Test Driven Development in .NET example for TDD in Visual Studio and .NET including WatiN test framework for web applications
- Video-Crashkurs 'Malen nach Zahlen': Test Driven Development Einführung für Software-Entwickler (deutsch)
Einzelnachweise
- Robert C. Martin in: The Transformation Priority Premise (abgerufen am 2. Februar 2016) "http://blog.8thlight.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html"
- Robert C. Martin: Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code. mitp-Verlag, ISBN 978-0-13-235088-4.
- Ken Pugh: Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley Professional, Boston 2011, ISBN 978-0-321-71408-4 (englisch).
- Andy Oram, Greg Wilson u. a.: Making Software - What Really Works And Why We Believe It. 1. Auflage. O'Reilly Media, 2010, ISBN 978-0-596-80832-7.
- http://www.throwtheswitch.org/#download-section (englisch) (abgerufen am 20. Januar 2017)