Definition „Testgetriebene Entwicklung“ Wie funktioniert Test-driven Development?

Anbieter zum Thema

OutSystems

Mit agilen Development-Methoden können Teams immer effizienter und wirtschaftlicher entwickeln. Zu den agilen Methoden gehört auch die testgetriebene Entwicklung. Getestet wird nicht die Entwicklung, die Entwicklung entsteht durchs Testen.

Im klassischen linearen Verständnis von Software Engineering ist der Platz eines Tests relativ klar: Eine Software, ein System oder einzelne Komponenten werden entwickelt und anschließend getestet.

Die testgetriebene Entwicklung (im Englischen Test-driven Development, TDD, oder Test First Development) kehrt diesen Prozess jedoch um.

Zunächst werden die Tests entwickelt und geschrieben, die einzelnen Testfälle werden dann genutzt, um den bestmöglichen Quellcode zu schreiben. In der agilen Softwareentwicklung kann dies Prozesse nicht nur beschleunigen, sondern liefert auch vergleichsweise schnell einen qualitativ hochwertigen und wartungsarmen Code.

Test First – Kent Becks Ansatz des Extreme Programming

Die testgetriebene Entwicklung unterliegt noch heute den Ansätzen, die der US-amerikanische Developer Kent Beck mit dem Extreme Programming begründete. Zunächst wird ein Test entwickelt, der eine einzelne Funktionalität prüfen soll. Idealerweise wird zu Beginn ein sehr einfaches Beispiel genommen, bei bestehendem Code können auch Fehler genutzt werden.

Die ersten Tests in diesem Ansatz schlagen fehl und werden als rot markiert. Der Code wird daraufhin angepasst, um den Test zu bestehen, so dass der nun passierte Test mit grün markiert wird. Ziel der Anpassung ist es, den Code so wenig wie möglich und so elegant wie möglich anzupassen.

Ist ein Test bestanden und ein Verhalten passiert einen gegebenen Test, so geht der Code ins Refactoring (die dritte Phase des Extreme Programming). In diesem Schritt wird Code weiter optimiert, Redundanzen werden entfernt, Abstraktionen genutzt. Auch im Refactoring durchläuft der Code mit jeder Änderung den eingangs passierten Test. So wird sichergestellt, dass auch nach Änderungen der Test weiterhin bestanden wird. Logisch betrachtet wird jede Änderung also von den Tests mitgedacht, wodurch die Entwicklung testgetrieben ist.

Mit weiteren Tests, welche die entsprechende Funktionalität der Unit testen, wird der Code daraufhin weiter optimiert. Eine Unit gilt dann als abgeschlossen, wenn die Entwickler*innen den Code nicht mehr weiter verbessern oder verknappen wollen/können, alle Tests bestanden werden und keine weiteren sinnvollen Tests durchgeführt werden können.

Die Tests für die Unit kommen wieder zum Einsatz, wenn im Zuge von Updates oder Anpassungen der Code umgeschrieben wird. Zwar können neue Tests hinzugefügt werden, doch die alten Tests muss der Code immer wieder bestehen, es sei denn, gewisse Funktionalitäten werden für obsolet erklärt.

Dieser gesamte Prozess trägt den Titel des Test-driven-Design-Zyklus.

Die Bedeutung von Refactoring im Test-driven Design

Das rote Fehlschlagen und grüne Bestehen sind nicht die einzigen Kernelemente der testgetriebenen Entwicklung, tatsächlich kommt dem Refactoring eine entscheidende Bedeutung zu. Den Code aufzuräumen, hat nicht nur den Zweck, einen möglichst einfach zu handhabenden, schlanken und wartungsarmen Code zu produzieren, sondern reduziert auch potentielle Fehlerquellen.

Schreiben Entwicklerinnen und Entwickler zu viel Produktivcode, so steigt das Risiko, dass die bestehenden Tests einer Unit nicht die gesamte Unit abdecken. TDD hilft also auch dabei, die Funktionalität des Codes mit möglichst wenig Code voranzutreiben, was in weniger Fehlerpotential resultiert.

Was die testgetriebene Entwicklung von anderen Testmethoden unterscheidet

Viele Teststrategien unterscheiden sich in der Art und Weise, wie sie eine Software testen. Bei der testgetriebenen Entwicklung jedoch wird nicht so sehr mit der Art des Tests gespielt, sondern mit der Platzierung des Testprozesses. Daher gilt Test-driven Development auch nicht als andersartige Testmethode, sondern als Designprinzip. Den Test zu schreiben und zu konzipieren, noch ehe Code geschrieben wird, ermöglicht im agilen Development einen einzigartigen Vorteil: Sie erkennen bereits sehr früh, ob Code verwendbar ist.

Die Vor- und Nachteile von testgetriebener Entwicklung

Der Fehler ist in der ersten Phase der testgetriebenen Entwicklung der Normfall. Andere Tests arbeiten mit der Annahme, der Code würde diese im ersten Anlauf bestehen – TDD hingegen lässt den Code absichtlich versagen. Der Fehler kann hier als etwas Positives betrachtet werden, da er im Folgenden ausgemerzt wird.

Weil Test Driven Design eine Designphilosophie ist und grundlegend anders arbeitet als andere Teststrategien, wird nicht erst ein beinahe fertige Code getestet. Die Tests arbeiten sich von der Mikro- in die Makroebene des Codes und testen so jede einzelne Codezeile. Andere Designschulen machen Eingriffe in den Code nur dann notwendig, wenn Fehler auftreten.

TDD beginnt mit dem Fehler und optimiert von dort aus den Code. Allerdings sind solche tiefen Eingriffe in die Arbeitsweise von Development Teams nicht alleine durch einen Mehraufwand kompensierbar. Agiles Arbeiten ist eine grundsätzlich anders funktionierende Methode, die nicht von jedem Team einfach implementiert werden kann.

Testgetriebene Entwicklung kann in Teams, die diese Arbeitsweise nicht gewöhnt sind, eher zu Verzögerungen und langsamerem Arbeiten führen. Für Legacy Code ist TDD oftmals gänzlich ungeeignet. Entwickler und Entwicklerinnen, die mit Test Driven Development arbeiten, haben jedoch einen sicheren und verlässlichen Überblick über jede einzelne Codezeile – noch ehe die erste davon geschrieben wurde.

(ID:48205886)