Was ist Test Driven Development, Ansätze und Vorteile

Test Driven Development (TDD) ist ein Softwareentwicklungsansatz, bei dem Testfälle entwickelt werden, um zu spezifizieren und zu validieren, was der Code tun wird.

Praktisch Testfälle für jede Funktion werden erstellt und getestet, bevor die Software veröffentlicht wird, und wenn der Test fehlschlägt, wird neuer Code geschrieben (oder umgeschrieben oder gepatcht), um den Test zu bestehen und den Code einfach und fehlerfrei zu machen.

Test Driven Development (TDD) beginnt mit dem Entwerfen und Entwickeln von Tests für jedes kleine Feature in einer Anwendung. Das TDD-Framework weist Entwickler an, nur dann neuen Code zu schreiben, wenn ein automatisierter Test fehlgeschlagen ist. Dieser Ansatz vermeidet Codeduplizierung. Das komplette TDD-Modul ist testgetriebene Entwicklung.

Test Driven Development (TDD) entstand als Teil eines größeren Softwaredesign-Paradigmas, das als Extreme Programming (XP) bekannt ist und Teil der agilen Softwareentwicklungsmethodik ist.

Das einfache Konzept von TDD besteht darin, fehlgeschlagene Tests zu schreiben und zu beheben, bevor neuer Code geschrieben wird (vor der Entwicklung). Dies trägt dazu bei, Codeduplizierung zu vermeiden, da wir jeweils nur eine kleine Menge Code schreiben, um Tests zu bestehen. (Tests sind nichts anderes als Anforderungsbedingungen, die wir testen müssen, um sie zu erfüllen).

Testgetriebene Entwicklung ist ein Prozess, bei dem vor der eigentlichen Entwicklung der Anwendung automatisierte Tests entwickelt und ausgeführt werden. Daher wird TDD manchmal auch als Test First Development bezeichnet.

Phasen des TDD-Ansatzes

Bevor neuer Code geschrieben wird, muss der Programmierer zunächst einen fehlgeschlagenen Komponententest erstellen. Dann erstellt der Programmierer – oder das Paar oder der Mob – gerade genug Code, um diese Anforderung zu erfüllen. Sobald der Test bestanden ist, kann der Programmierer das Projekt umgestalten und Verbesserungen vornehmen, ohne das Verhalten zu ändern.

Während sich TDD auf Programmiererinteraktionen auf Einheitenebene konzentriert, gibt es andere beliebte Methoden, wie z.

Diese Methoden umfassen das Erstellen von Beispielen aus der Praxis als gemeinsame Tests zwischen den Ingenieuren und dem Kunden vor dem Codieren und das anschließende Ausführen der Tests nach dem Codieren, um zu demonstrieren, dass der Code implementiert ist. Wenn die Tests im Voraus bekannt sind, verbessert sich die Qualität beim ersten Mal. ATDD und BDD erfordern, dass Entwickler, Tester und die Geschäftsseite zusammenarbeiten, um sich die Software und ihre Auswirkungen vorzustellen und zu diskutieren, bevor der Code erstellt wird.

Vorteile von TDD

Testgetriebene Entwicklung kann qualitativ hochwertige Anwendungen in kürzerer Zeit produzieren, als dies mit älteren Methoden möglich ist. Eine erfolgreiche Implementierung von TDD erfordert, dass Entwickler und Tester genau voraussehen, wie die Anwendung und ihre Funktionalität in der realen Welt verwendet werden.

TDD erstellt als Nebeneffekt eine Regressionstestsuite, die manuelles Testen durch Menschen minimieren kann, Probleme früher findet und zu schnelleren Lösungen führt. Der methodische Charakter von TDD gewährleistet eine viel höhere erstmalige Abdeckung und Qualität als die klassischen Phasencodezyklen > Test > Fix > Retest. Da das Testen früh im Designzyklus durchgeführt wird, wird der Zeit- und Geldaufwand für das spätere Debuggen minimiert.

Erwartete Vorteile:

• deutliche Reduzierung der Fehlerquoten auf Kosten eines moderaten Anstiegs des anfänglichen Entwicklungsaufwands
• Overhead-Kosten werden durch eine Reduzierung des Aufwands in der Endphase von Projekten mehr als kompensiert
• TDD führt zu besseren Designqualitäten im Code und ganz allgemein zu einem höheren Maß an "interner" oder technischer Qualität, beispielsweise durch Verbesserung der Kohäsions- und Kopplungsmetriken

Nachteile von TDD

TDD erfordert beträchtliche Fähigkeiten, um erfolgreich zu sein, insbesondere auf Einheitenebene. Viele Legacy-Systeme sind einfach nicht auf Unit-Tests ausgelegt, was es unmöglich macht, Komponenten zum Testen zu isolieren.

Außerdem fehlt vielen Programmierern die Fähigkeit, sauberen Code zu isolieren und zu erstellen. Alle Teammitglieder müssen Komponententests erstellen und pflegen, da sie sonst schnell veraltet sind. Und eine Organisation, die sich mit TDD befasst, muss Zeit investieren, jetzt etwas langsamer fahren, um später schneller zu werden.

Schließlich sind die Endergebnisse von TDD wie bei jeder Methode nur so gut wie die verwendeten Tests, wie genau sie durchgeführt wurden und inwieweit sie die Bedingungen nachahmen, denen die Benutzer des Endprodukts ausgesetzt sind.

Häufige Fehler:

• vergessen, häufig Tests durchzuführen
• Schreiben Sie zu viele Tests auf einmal
• Schreiben Sie Tests, die zu groß oder grob sind
• Schreiben allzu trivialer Tests, wie z. B. das Weglassen von Behauptungen
• Schreiben Sie Tests für trivialen Code
• teilweise Übernahme: Nur wenige Entwickler in einer Arbeitsgruppe verwenden TDD
• schlechte Wartung der Testsuite, was am häufigsten zu einer Testsuite mit einer unerschwinglich langen Laufzeit führt
• Testsuite aufgegeben (d. h. selten oder nie ausgeführt) – manchmal aufgrund schlechter Wartung, manchmal aufgrund von Teamfluktuation

TDD-Philosophie

TDD ermöglicht es dem Programmierer, beim Schreiben von Software kleine Schritte zu unternehmen. Der Test wird vor dem Testen der Funktionalität geschrieben und stellt sicher, dass die Anwendung für die Testbarkeit geeignet ist. Das Testen einer kleinen Codemenge wird durchgeführt, um Fehler abzufangen, die im getesteten Code auftreten. Anschließend wird die Funktionalität implementiert. Dies wird als „Rot-Grün-Refaktorisierung“ bezeichnet, wobei Rot einen Fehler und Grün einen Bestanden bedeutet. Diese Schritte werden dann wiederholt. Das erste Ziel eines Programmierers ist es, sich auf die anstehende Aufgabe zu konzentrieren und sie zu bewältigen.

Die verschiedenen Phasen eines testgetriebenen Entwicklungszyklus sind:

• Test hinzufügen: Jede neue Funktion in TDD beginnt mit einem Test, der fehlschlagen muss, da er eingerichtet wird, bevor eine Funktion implementiert wird. Voraussetzung für das Schreiben eines Tests vor der Implementierung des Features ist ein klares Verständnis der Anforderung durch den Entwickler. Dies wird durch User Stories und Use Cases erreicht. Ein Entwickler versteht also die Anforderung, bevor er den Programmcode schreibt.
• Führen Sie alle Tests durch und prüfen Sie, ob der neue Code fehlschlägt: Dadurch wird sichergestellt, dass die Testumgebung korrekt funktioniert und dass der neue Test nicht ohne neuen Code fehlschlägt. Dieser Schritt verifiziert auch den Test und eliminiert die Möglichkeit, dass der neue Test immer bestanden wird.
• Code schreiben: Der nächste Schritt ist das Schreiben des Codes, der den Test löscht. Der neue Code ist nicht perfekt, wird aber später gemäß den Anforderungen modifiziert. Es ist nur zum Testen konzipiert und enthält keine weiteren Funktionen.
• Führen Sie automatisierte Tests durch: Wenn jeder erstellte Testfall den Test problemlos besteht, bedeutet dies, dass der Code alle erforderlichen Spezifikationen erfüllt. Dann kann die letzte Phase des Zyklus gestartet werden.
• Refactoring-Code: Dies ähnelt dem Entfernen von Duplikaten. Ein Refactoring unterbricht keine vorhandene Funktionalität und hilft, Duplikate zwischen Produktions- und Testcode zu entfernen. Der Code wird nun nach Bedarf bereinigt.
• Wiederholen: Der Zyklus wiederholt sich wie in den vorherigen Fällen mit einem neuen Test. Die wesentliche Anforderung ist, dass die Schrittgröße klein ist, mit etwa 1–10 Änderungen zwischen jedem Testlauf. Wenn der neue Code einen neuen Test nicht besteht, sollte der Programmierer mehr debuggen. Kontinuierliche Integration bietet umkehrbare Checkpoints.

Ercole Palmeri