Was ist testgetriebene Entwicklung? Oder TDD?

Was ist testgetriebene Entwicklung? Oder TDD?

Test Driven Development oder TDD, wie es in Entwicklerkreisen gerne genannt wird, ist ein wichtiger Aspekt des Softwareentwicklungsprozesses. Durch diesen Ansatz ist es einfacher zu testen, was ein bestimmter Code leisten würde. Testfälle für jede Funktionalität der Softwareanwendung werden erstellt, und wenn eine bestimmte Funktionalität in einem Test fehlschlägt, wird der Code überarbeitet und neue Codes erstellt. Auch der neue Code müsste den Test bestehen und fehlerfrei sein. Der Entwickler muss nur dann einen neuen Code schreiben, wenn der automatisierte Test des Codes fehlgeschlagen ist, sodass es für jede noch so kleine Funktionalität einen Testfall gibt. Und bei TDD dreht sich alles darum, Tests für jede einzelne Funktionalität in der Anwendung zu entwerfen und zu entwickeln.

Der Name Test Driven Development weist darauf hin, dass es der Prozess der richtigen Durchführung von Tests ist, der die Softwareentwicklung vorantreibt. Daher leitet der Prozess selbst seine Wurzeln aus der agilen Methodik und der Extreme-Programmierung. Dieser Prozess stellt sicher, dass Entwickler widerstandsfähigen und langfristigen Code erstellen und pflegen.

Der Prozess für TDD besteht also darin, zuerst den Komponententest zu schreiben und dann, wenn der Test fehlschlägt, die Codeänderungen zu implementieren. Dies hilft auch, Codeduplizierungen zu vermeiden. Das Ganze läuft darauf ab, fehlgeschlagene Tests vor der eigentlichen Entwicklung zu schreiben und zu korrigieren. Damit der TDD erfolgreich funktioniert, ist es jedoch ratsam, die Testfälle in einfache Testfälle zu schreiben. Für eine komplexe Geschäftslogik wäre es wirklich schwierig, eine Kombination von Testfällen zu schreiben und den vollen Erfolg zu erzielen. Es besteht die Möglichkeit, dass Sie einige Tests verpassen, daher ist dies keine leichte Aufgabe.

Unterschied zwischen TDD und traditionellem Testen

Herkömmliche Tests sind zeitaufwendiger als TDD und basieren auf der Wiederholung eines kurzen Entwicklungszyklus. Zuerst wird der Test von Anfang an geschrieben, dann wird der Programmcode geschrieben, gefolgt von dem gewünschten Verhalten des Systems. Wenn der schriftliche Test bestanden ist (Prüfung der Korrektheit der Arbeit des ungeschriebenen Codes), wird ein Refactoring des geschriebenen Codes durchgeführt.

Anfangs wird TDD auch zeitaufwändig sein, aber mit der Zeit wird sich der Entwickler daran gewöhnen, da der Entwicklungsprozess strukturierter wird. Wenn Sie beispielsweise einen Entwickler einstellen, wird dieser entscheiden, was er schreibt und dann, wie er es schreibt.

Herkömmliche Tests sind erfolgreich, wenn sie einen oder mehrere Fehler richtig finden. Genauso wie TDD. Fehler zu finden ist eigentlich ein gutes Zeichen, denn dann wissen Sie, dass Sie den Fehler beheben und von dort aus weitermachen müssen. TDD gibt Ihnen auch mehr Sicherheit, wenn Sie das Programm freigeben, und stellt sicher, dass es die Anforderungen erfüllt, für die es definiert ist.

Beim traditionellen Testen liegt der Fokus mehr auf dem Testfalldesign, während bei TDD der Fokus mehr auf dem Produktionscode liegt, um zu überprüfen, ob das Testen nach Plan funktioniert.

TDD bietet Ihnen eine 100%ige Testabdeckung, wobei für jede einzelne Codezeile getestet wird, was bei herkömmlichen Tests nicht der Fall ist.

Wenn der Projektumfang wirklich groß ist, muss man bei der Durchführung der Tests sehr gründlich vorgehen. Und es besteht die Möglichkeit, dass sich die Tests verzögern und die Budget- und Zeitbeschränkungen überschreiten.

TDD mag schwer zu schreiben sein und die Entwicklungszeit verlangsamen, aber auf lange Sicht würde es sich definitiv auszahlen.

Ein weiterer Nachteil von TDD besteht darin, dass das Konzept schwer auf existierenden Legacy-Code anzuwenden ist.

Es ist immer gut, wenn der Test fehlschlägt, bevor Sie ein Projekt freigeben, denn dann wissen Sie, dass Sie einen gültigen Test durchgeführt haben. Durch TDD wissen Sie, dass Ihr System die Anforderungen erfüllt, für die es entwickelt wurde. Der Fokus liegt also eher auf Produktionscode für TDD, da dieser sicherstellt, dass das Testen richtig funktioniert. Und wenn die Software alle dafür vorgesehenen Anforderungen erfüllt.

Die verschiedenen Phasen einer testgetriebenen Entwicklung

Es gibt drei verschiedene Stufen von TDD: Rot, Grün und Refactor

Befolgen Sie diese Reihenfolge der Schritte, um sicherzustellen, dass Sie Tests für den Code haben, den Sie schreiben, sodass Sie die Codes nur für die Tests schreiben müssen, die Sie gerade durchführen.

Die Rote Bühne

Die Idee der roten Phase ist, den Test zum Scheitern zu bringen, und auch die schwierigste Phase, da die Entwicklung keinen Code schreiben muss. Neue Entwickler müssen es schwierig finden, weil sie verwirrt wären, was sie testen sollen, ohne den Code dafür zu haben. Aber es ist eine gewohnheitsmäßige Sache und mit der Erfahrung wird es glatt. Der erste Test wird geschrieben, ohne Code zu schreiben und Klasse und Methode zu deklarieren, und der Test wird einen Kompilierungsfehler aufweisen. Der nächste Schritt wäre, den Kompilierungsfehler zu beheben und den Test auszuführen, um ihn zu fehlschlagen. Dies verursacht die rote Flagge.

Die Grüne Phase

Nach der roten Phase wäre der nächste Schritt, den Code zu schreiben. Dieser Code muss den ersten Test bestehen. Gerade genug Code zu schreiben, um sicherzustellen, dass nur der erste Test besteht, ist eine Hürde, vor der viele Entwickler anfangs stehen. Denn im nächsten Test müsste es fehlschlagen, gefolgt von neuem Code, um sie zu bestehen.

Die Refraktorphase

In den ersten beiden Phasen, in denen der Test erst durchfallen und dann bestehen muss, war es das Ziel, die Tests dann zum Bestehen zu bringen. In der Refraktor-Phase müssen jedoch andere Faktoren berücksichtigt werden, wie die Codequalität, die Wartbarkeit des Codes, die Lesbarkeit des Codes usw. Der Fokus liegt hier also auf diesen Aspekten, auf die sich die Unit-Tests konzentrieren werden. In der Refactoring-Phase müssen Sie sich keine Sorgen über fehlende Funktionalität machen, da die Testfälle bei Codeänderungen automatisch auch dem funktionalen Teil entsprechen.

TDD passt gut in die agile Methodik

Es liegt auf der Hand, dass sich Projektanforderungen bis weit in die Entwicklungsphase hinein ändern können, so dass die Zusammenarbeit von TDD mit der agilen Entwicklung definitiv zum Erfolg führt und Projekte entsprechend den Kundenanforderungen entwickelt. Mit testgetriebener Entwicklung erhalten Sie ein früheres Feedback zum Projekt, an dem Sie problemlos arbeiten können.

Es würde auch dazu beitragen, die kritischen Engpässe zu antizipieren und zu reduzieren und sicherzustellen, dass das Projekt wie geplant voranschreitet. Entwicklerteams können viel Zeit sparen, da die Tests viel früher in der Projektentwicklung erstellt werden und sie sich nicht um umfangreiche Testskripte kümmern müssen.

Fazit

Test Driven Development ist eine Technik, die zwar zeitaufwändig ist, aber insofern wertvoll ist, als sie Ihr Projekt in die richtige Richtung lenkt, indem sie korrektes Feedback zum Projekt erhält und Fehler erkennt. Es ist jedoch eine viel bessere Option als herkömmliche Tests, da es mehr Zeit und Geld erfordert.

Interessante Links:

Testgetriebene Entwicklung: Was es ist und was es nicht ist.

Mehr Informationen über Testgetriebene Entwicklung

Bilder: Canva

Der Autor: Sascha Thattil arbeitet bei Software-Developer-India.com die zur YUHIRO Gruppe gehört. YUHIRO ist ein deutsch-indisches Unternehmen, das Programmierer an IT-Unternehmen, Agenturen und IT-Abteilungen vermittelt.