Die Softwareentwicklung besteht aus mehreren Schritten, die durch das PDCA-Prinzip (Plan - Do - Check - Act) gekennzeichnet sind. Einer der wichtigsten Schritte im Deming-Rad ist die Phase der Überprüfung (oder des Testens). Hierfür gibt es verschiedene Methoden, die die Qualität und Zuverlässigkeit von Software überprüfen können. Eine davon ist Test Driven Development.
Worum handelt es sich ? Was sind die Vor- und Nachteile dieser Methode? Und vor allem: Wie kann man sie umsetzen? DataScientest beantwortet all deine Fragen.
Was ist Test Driven Development?
Definition von TDD
Test Driven Development (Testgetriebene Entwicklung) ist eine Methode zur Entwicklung von Software, die auf einer Test-First-Politik basiert. Die Idee ist es, die Programmierung von Software oder Anwendungen durch eine Reihe von Tests zu leiten.
Dies geschieht noch vor dem Schreiben des Codes.
Sobald die Entwickler auf Fehler stoßen, werden diese nach und nach behoben. Durch die regelmäßige Durchführung von Tests können alle Anomalien, die im Quellcode entdeckt werden, schnell (fast in Echtzeit) beseitigt werden. In dieser Hinsicht entspricht TDD perfekt den Anforderungen der agilen Methode, da es bedeutet, in Iterationen vorzugehen, um die Software schrittweise zu verbessern.
Gut zu wissen: Dieser Ansatz wurde von dem amerikanischen Entwickler Kent Beck initiiert. Er kehrte den verwendeten Prozess einfach um, indem er zuerst den Test und dann den Code schrieb. Dadurch konnte er die Qualität des Codes verbessern.
Test Driven Development und andere Testverfahren
Test Driven Development ist eine sehr bekannte Methode unter DevOps, aber bei weitem nicht die einzige Methode, um die Qualität von Software zu überprüfen:
- Test Driven Development Acceptance (oder ATDD): Dies ist eine ergänzende Methode zu TDD. In diesem Fall konzentrieren sich die Entwickler vor allem darauf, zu überprüfen, ob ein Anwendungsszenario mit den angestrebten Zielen übereinstimmt. Dieser Ansatz konzentriert sich auf das Testen von funktionalen Anwendungen.
- Behavior driven development: Auch als verhaltensgesteuerte Programmierung bezeichnet, konzentriert sich BDD auf das gewünschte Verhalten und nicht auf die Korrektheit des Codes.
- Domain Driven Design (DDD): Hier geht es vor allem darum, eine gemeinsame Vision und eine gemeinsame Sprache für alle Beteiligten zu definieren.
Alle diese Methoden ergänzen sich gegenseitig. Zusammen ermöglichen sie es, bessere, skalierbare und zuverlässige Software zu entwickeln und gleichzeitig die technischen Schulden zu senken.
Was sind die Vor- und Nachteile des Test Driven Development?
Vorteile des Test Driven Development
Heutzutage wird Test Driven Development für die meisten Programmierprozesse empfohlen. Und das aus gutem Grund, denn diese Art der Überprüfung bringt eine Vielzahl von Vorteilen mit sich:
- Die Machbarkeit der Software voraussehen: Indem sie die Tests schreiben, bevor sie den Code schreiben, stellen die Entwickler sicher, dass die Software so konzipiert ist, dass die Ziele erreicht werden.
- Tatsächlich entsprechen die Tests eher den geschäftlichen Anforderungen. Und was noch wichtiger ist: DevOps sind in der Lage, mehr Unit-Tests abzudecken.
- Zeit sparen: Das Schreiben von Tests im Vorfeld verhindert auch, dass Zeit mit der Entwicklung von Funktionen verschwendet wird, die nicht den angestrebten Zielen entsprechen.
- Fehler minimieren: Da die Entwicklung durch Tests gesteuert wird, können die Entwickler Fehler fast in Echtzeit erkennen. Dadurch werden Fehler nach dem Einsatz minimiert.
- Vereinfachung der Wartung: Die Reduzierung von Fehlern spart auch Zeit bei der Wartung und Überwartung.
Nachteile des Test Driven Development
Trotz aller Vorteile von Test Driven Development sollte man sich auch seiner Grenzen bewusst sein.
Zum einen setzt dieses Prüfverfahren ein umfassendes Verständnis des Codes voraus. Das bedeutet, dass du mehr Zeit für die Einarbeitung benötigst, bevor du mit dem Schreiben des Codes beginnen kannst.
Andererseits besteht das Ziel des testgetriebenen Einsatzes vor allem darin, die Genauigkeit des Codes zu überprüfen. Diese Methode hält sich nicht damit auf, die Nutzung der Software und ihrer Funktionen zu überwachen. Aus diesem Grund muss TDD in der Regel durch andere Testverfahren (insbesondere BDT) ergänzt werden.
Was sind die drei Phasen des Test Driven Development?
Test Driven Development basiert auf drei Grundgesetzen, nämlich :
- „Du musst einen Test schreiben, der fehlschlägt, bevor du den entsprechenden Produktionscode schreiben kannst“.
- „Du musst jeweils nur eine Assertion schreiben, durch die der Test fehlschlägt oder die beim Kompilieren fehlschlägt“.
- „Du musst das Minimum an Produktionscode schreiben, damit die Assertion des fehlgeschlagenen Tests erfüllt wird“.
Wenn diese drei Gesetze in einer einzigen Iteration zusammengeführt werden, bilden sie einen TDD-Nano-Zyklus. Traditionell werden sie in einem Zyklus mit drei Phasen dargestellt: red (rot), green (grün) und refactor (Überarbeitung).
Rote Phase
Im ersten Schritt der Test Driven Development muss der Entwickler ein Problem durch das Schreiben eines Unit-Tests beschreiben. Da der Code aber noch nicht existiert, wird der Test bei seiner Ausführung zwangsläufig fehlschlagen. Daher das Symbol mit der roten Farbe.
Um den Test durchzuführen, versetzt sich der Entwickler in die Lage des Endbenutzers, indem er die fehlenden Komponenten beschreibt, die für das Funktionieren des Codes unerlässlich sind. Dabei handelt es sich jedoch um Komponenten, die noch nicht implementiert wurden.
Grüne Phase
Das Ziel dieser Phase ist es, den Test zu bestehen. Dazu schreibt der Entwickler ein Stück Code, indem er den zuvor geschriebenen Unit-Test vervollständigt. Es muss grün werden. Es ist also eine Suchphase, in der der Entwickler eine Lösung für das gestellte Problem finden muss.
Aber Vorsicht: In dieser Phase der Test Driven Development darf der DevOps nicht nach komplexen Lösungen suchen. Er muss sich auf das Wesentliche konzentrieren, um den Produktionscode auf grün zu schalten. Er überprüft dann, ob der Code erfolgreich ist, indem er weitere Tests ausführt.
Refactor-Phase
Erst wenn der Entwickler die Lösung gefunden hat, kann er zum Refactoring übergehen. Er kann nun den Code überarbeiten, strukturieren, lesbarer machen und eventuell ergänzen. Dabei darf er jedoch das Verhalten des Codes nicht verändern. Das heißt, er muss jede Funktionalität beibehalten. Auch hier muss er überprüfen, dass jeder Test validiert wird, wenn eine neue Funktion hinzugefügt wird.
Beherrsche TDD mit DataScientest
Der Test Driven Development-Ansatz passt perfekt zur CI/CD-Arbeitsweise (Continuous Integration and Deployment), die für DevOps typisch ist. Als zukünftiger Entwickler musst du diesen Ansatz beherrschen, um den Code in allen Phasen der Entwicklung zu optimieren. Um ihn richtig zu integrieren, ist es besser, sich darin zu schulen. Deshalb bietet dir DataScientest eine Ausbildung an, die sowohl praktische Kurse als auch die besten Methoden vereint. Mach mit!
