Was ist testgetriebene Entwicklung (TDD)?

Die Entwickler schreiben genügend Code, um jeden Test zu bestehen. Dann werden sowohl der Test als auch der Code verfeinert, bevor ein neuer Test und dann eine neue Funktion in Angriff genommen werden.

Die testgetriebene Entwicklung zwingt Entwickler im Wesentlichen dazu, ihren Code in kürzeren Feedbackzyklen zu verlangsamen, zu validieren und zu verfeinern. Obwohl nicht erforderlich, ermutigen DevOps-Teams Programmierer, von Anfängern bis hin zu erfahrenen Profis, TDD in einer Vielzahl von Programmiersprachen zu verwenden. Zum Beispiel Java, Python usw., Anwendungsprogrammierschnittstellen (APIs) und Programmanwendungen.

Die Programmierung in diesem Stil stärkt die Beziehung zwischen Codierung, Testen (in Form von automatisierten Tests auf Unit-Ebene) und Codedesign. Die testgetriebene Entwicklung kann zwar die Vorabentwicklungszeit verlängern, aber es hat sich gezeigt, dass sie die Codefunktionalität und -geschicklichkeit verbessert und insgesamt Zeit spart.

Durch die sofortige Identifizierung und Behebung von Fehlern können Entwickler, die TDD verwenden, verhindern, dass kleine Probleme zu größeren Problemen werden. Bei der testgetriebenen Entwicklung müssen Entwickler ihren Code während des Betriebs sowohl validieren als auch verfeinern, was abschließende Qualitätsprüfungen und Korrekturen vereinfacht. 

Alternative Testframeworks umfassen das Schreiben des Produktionscodes vor dem Verfassen aller automatisierten Tests oder das Erstellen der gesamten Testsuite vor dem Schreiben des Produktionscodes. Diese Methoden sind zwar nicht zwangsläufig unwirksam, aber es hat sich gezeigt, dass sie die erforderliche Debugging-Zeit erhöhen, insbesondere bei größeren und komplexeren Projekten.

Die testgetriebene Entwicklung wird zwar häufig für die Erstellung von neuem Produktionscode verwendet, wird aber auch häufig zur Verbesserung des Debugging von Altlasten eingesetzt, die mit älteren oder anderen Techniken entwickelt wurden. 

Die testgetriebene Entwicklung kehrt den traditionellen Entwicklungsprozess um, indem sie das Testen vor die Entwicklung stellt. Als iterativer Ansatz verbessert testgetriebene Entwicklung die Codequalität und Lesbarkeit, indem testbare Workflows gefördert werden, die zu qualitativ hochwertigem Code auf Einheitsebene führen. Wenn Entwickler Komponententests implementieren, konzentrieren sie sich auf einen kleinen Teil der Logik, wie zum Beispiel einen einzelnen Algorithmus. Das Schreiben von Code speziell zum Bestehen von Tests führt nicht nur zu saubererem, haltbarerem Code, sondern trägt auch zur Verbesserung der Dokumentation bei. 

Es gibt zwei Hauptebenen der testgetriebenen Entwicklung.

Bei Akzeptanz-TDD - manchmal auch Behavior-Driven Development (BDD) genannt - schreiben die Programmierer einen einzigen Akzeptanztest und dann genügend neuen Code, um ihn zu bestehen. Abnahmetests werden manchmal auch als Kundentests oder Kundenakzeptanztests bezeichnet.

Sie können im Allgemeinen als Testfälle verstanden werden, die für die von den Produkt-Stakeholdern angegebene Mindestfunktionalität erforderlich sind. ATDD ist bestrebt, detaillierte, ausführbare Anforderungen zu identifizieren. Abnahmetests können mit verschiedenen Testtools wie Fitnesse oder RSpec durchgeführt werden.

Manchmal auch einfach TDD genannt, erfordert Entwickler-TDD, dass Programmierer einzelne Tests schreiben, um ihre eigene Lösung für einen ATDD-Test zu bewerten. Entwickler TDD verwendet Testautomatisierungstools wie JUnit oder VBUnit. 

Bei einer testgetriebenen Entwicklungsstrategie schreiben Programmierer zunächst Tests, um jedes einzelne Element oder jede Funktion einer Software zu überprüfen, bevor sie genügend Code schreiben, um diesen einzelnen Test zu bestehen. Nach Abschluss wird die Software erneut getestet, und wenn sie erfolgreich ist, wird der Code verfeinert (ein Prozess, der als Refactoring bezeichnet wird), sodass er nur noch wesentliche Elemente enthält. Entwickler wiederholen diesen Vorgang dann für jede weitere Softwarefunktion. 

Der testgetriebene Entwicklungsprozess ist in fünf einzelne Schritte unterteilt:

1. Bevor der Code für eine bestimmte Softwarefunktion geschrieben wird, schreiben die Entwickler zunächst einen individuellen Unit-Test für diese Funktion.
2. Die Entwickler führen dann den Test aus, der scheitert, da die Codefunktion noch nicht geschrieben wurde. Dieser Schritt ist wichtig, um zu bestätigen, dass der Test selbst funktionsfähig ist und keine falsch positiven Ergebnisse liefert. Wenn der Code erfolgreich ist, bedeutet dies, dass der Test neu geschrieben werden muss.
3. Wenn das Programm den Test nicht besteht, schreiben die Entwickler nur so viel zusätzlichen Softwarecode, dass der Test bestanden wird. 
4. Wenn der Code den Test bestehen kann, werden sowohl der Test als auch der Code überarbeitet, um ihn zu vereinfachen und unnötigen Code zu eliminieren. 
5. Wenn die ausreichend umgestaltete Software den umgestalteten Test besteht, gehen die Entwickler zur nächsten gewünschten Softwarefunktion über. Anschließend schreiben die Tester Tests für jede neue Funktion und führen diese durch. 

Einfach ausgedrückt folgt der testgetriebene Entwicklungsprozess einem wiederholbaren Kreislauf, der als Rot-Grün-Refaktor-Zyklus bezeichnet wird. Die Schritte des Zyklus sind:

• Rot: Schreiben Sie einen fehlgeschlagenen Test für das beabsichtigte Softwareverhalten. 

• Grün: Schreiben Sie mehr, damit der Test klappt.

• Umgestalten: Verfeinern Sie den Code, um die Standards der Einfachheit so weit wie möglich zu erfüllen und trotzdem den Test zu bestehen.

Die genauen Ursprünge der testgetriebenen Entwicklung sind zwar unbekannt, aber das Konzept, zuerst die Tests und dann den Produktionscode zu schreiben, war bis Mitte der 1990er Jahre keine gängige Praxis. Zuvor trennte das Testen von Frameworks die Entwickler vom Testen ihrer eigenen Codebasen. Mit der Weiterentwicklung des Software-Engineerings forderten die DevOps-Teams jedoch schnellere und flexiblere Methoden, um den Anforderungen der Stakeholder gerecht zu werden, insbesondere angesichts der sich schnell ändernden Anforderungen der Stakeholder. 

Die testgetriebene Entwicklung hat sich aus und neben verschiedenen neuartigen Test-Frameworks entwickelt und wurde als modulare Komponente auch in verschiedene andere Frameworks übernommen. Vor allem ist TDD Teil des Konzepts von Extreme Programming (XP), einem flexiblen Framework für die Softwareentwicklung, das entwickelt wurde, um sowohl die Softwarequalität als auch die Lebensqualität der Entwickler zu verbessern.

Software-Engineer Kent Beck, eine wichtige Persönlichkeit der flexiblen Community und Begründer von Extreme Programming, wird für die „Wiederentdeckung“ der testgetriebenen Entwicklung verantwortlich gemacht. So Beck: 

„Die ursprüngliche Beschreibung von TDD stand in einem alten Buch über Programmierung. Es hieß, dass Sie das Eingabeband nehmen, das erwartete Ausgabeband manuell eingeben und dann programmieren, bis das tatsächliche Ausgabeband mit der erwarteten Ausgabe übereinstimmt. Nachdem ich das erste xUnit-Framework in Smalltalk geschrieben hatte, erinnerte ich mich daran, dies gelesen zu haben und probierte es aus. Das war für mich der Ursprung von TDD. Wenn ich älteren Programmierern TDD beschreibe, höre ich oft: ‚Natürlich. Wie könnten Sie sonst programmieren?' Daher bezeichne ich meine Rolle als ‚Wiederentdeckung' von TDD.“ 

Zu den wichtigsten Daten in der Entwicklung der testgetriebenen Entwicklung gehören:

• 1976: Glenford Myers veröffentlicht Software Reliability, in der er argumentiert, dass „ein Entwickler niemals seinen eigenen Code testen sollte“. Auch wenn Myers nicht der Urheber dieses Konzepts war, so verlieh seine Arbeit doch einer weit verbreiteten Vorstellung Glaubwürdigkeit, die sich in den kommenden Jahren durchsetzen sollte. 

• 1990: Zu Beginn des Jahrzehnts dominierte die „Black-Box“-Technik das Softwaretesten . In dieser Art von Test-Framework behandeln die Tester die Software wie eine „Blackbox“, undurchdringlich und nicht erkennbar. Beim Blackbox-Testing werden Tester eingesetzt, die keine Kenntnis vom Innenleben der Software haben. 

• 1994: Kent Beck entwickelt SUnit, ein Smalltalk-Testframework, und legt damit den Grundstein für einen testorientierten Ansatz zur Optimierung der Codebasis. 

• 1999–2002: Während die flexible Entwicklungsbewegung an Fahrt gewinnt, entwickelt Kent Beck das Konzept des Extreme Programming, indem er die testgetriebene Entwicklung systematisiert und das wichtige Konzept der Mock-Objekte einführt. TDD verwendet Mock-Objekte, um das Verhalten realer Abhängigkeiten (z. B. Datenbanken, externe Dienste usw.) während des Tests zu simulieren. Diese Methode hilft Entwicklern, ihren Testcode auf wartbare Scheinobjekte zu konzentrieren, deren genaue Leistung überprüft werden kann. Ein fehlgeschlagener Test, bei dem ein Pseudoobjekt verwendet wird, kann eine potenziell falsch konfigurierte Abhängigkeit als Fehlerquelle beseitigen. 

• 2003: Kent Beck veröffentlicht Test Driven Development: By Example, um die Praxis in der breiteren Entwicklergemeinschaft bekannt zu machen und das entwicklergesteuerte Testen weiter zu legitimieren. 

Als Komponente des Extreme Programmings hat sich die testgetriebene Entwicklung als vorteilhaft erwiesen, um besseren Code zu schaffen, sondern auch um die Programmierer selbst zu verbessern. TDD kann es Programmierern ermöglichen, eine bessere Erkenntnis in ihre Projekte zu erhalten und die Programmentwicklung voranzutreiben. Durch die Zentrierung des Testfalls vor der Implementierung jeder Funktion müssen Entwickler visualisieren, wie eine Funktion von einem Client oder Benutzer verwendet wird. Dieser Ansatz positioniert die Produktschnittstelle vor der Implementierung und hilft Entwicklern, Anwendungen zu erstellen, die stärker auf die Benutzer ausgerichtet sind. 

Zu den zusätzlichen Vorteilen der testgetriebenen Entwicklung gehören:

• Umfassende Testabdeckung: TDD wird manchmal auch als Spezifikations- oder Dokumentationstool bezeichnet, da die Praxis sicherstellt, dass der gesamte Code von mindestens einem Test abgedeckt wird. 

• Verbesserte Dokumentation: Aus dem gleichen Grund, aus dem TDD eine umfassende Abdeckung bietet, liefert es auch eine robuste Dokumentation und Spezifikation. Dieses System hilft Entwicklern, Projektmanagern und anderen Stakeholdern, Funktionen und Anforderungen zu validieren und die Ordnung während des Projektlebenszyklus zu etablieren. 

• Verbessertes Selbstvertrauen: Entwickler und DevOps-Teams, die TDD einsetzen, gewinnen nicht nur mehr Vertrauen in ihren Code, sondern auch in ihre Tests. 

• Erleichtert die kontinuierliche Integration: TDD eignet sich gut für kontinuierliche Integrationspraktiken, bei denen der Live-Code kontinuierlich mit neuen Funktionen und Patches aktualisiert wird. 

• Reduzierte Fehlersuche: TDD schiebt das Testen in den Entwicklungsprozess vor und reduziert so die Notwendigkeit umfangreicher Fehlersuche am Ende der Entwicklung. 

• Verbesserte Klarheit der Anforderungen: TDD hilft Entwicklern, sich ein klares Verständnis für jede spezifische Programmanforderung zu verschaffen, bevor sie mit der Arbeit beginnen. 

• Verbesserte Produktivität: TDD wird oft mit einer erhöhten Produktivität unter Entwicklern in Verbindung gebracht, da der Prozess dazu beiträgt, große Projekte in kleinere, besser durchführbare Schritte zu zerlegen. 

• Verstärkt das einfache Design: Der entscheidende dritte Schritt im Grün-Red-Refaktor-Zyklus von TDD erfordert von den Entwicklern eine Umstrukturierung und Vereinfachung ihres Codes. Diese Vorgehensweise verbessert die allgemeine Einfachheit und das hochwertige Design. 

• Stärkt mentale Modelle: Durch die Untersuchung und Integration jeder einzelnen Funktion oder Anforderung hilft TDD den Programmierern dabei, ein solides mentales Modell des jeweiligen Codes zu entwickeln. Dieses mentale Modell hilft den Entwicklern, die Gesamtfunktionen und Anforderungen des Codes zu visualisieren, während sie daran arbeiten. 

• Verbesserte Systemstabilität: Der Einsatz der testgetriebenen Entwicklung verbessert nachweislich die allgemeine Stabilität der Anwendung, indem robuster, gut getesteter Code erstellt wird, der an hohe Standards für eine einfache Gestaltung angepasst wird. 

Obwohl der Einsatz von testgetriebener Entwicklung (TDD) viele wertvolle Nutzen bietet, ist er nicht ohne Herausforderungen. Die Schwere dieser Herausforderungen kann zwar projektabhängig sein oder durch verschiedene andere Techniken abgemildert werden, doch zu den Nachteilen der TDD gehören:

• Erhöhtes Codevolumen: TDD erfordert, dass Programmierer nicht nur Code für jede erforderliche Funktion schreiben, sondern auch Tests für jede Funktion schreiben. Das Hinzufügen des Testcodes mit dem Produktcode ergibt größere Ergebnisse in der Gesamtcodebasis. 

• Falsches Vertrauen: Da jede Funktion so geschrieben ist, dass sie einen Test besteht, können Programmierer und Projektmanager ein falsches Sicherheitsgefühl in Bezug auf die Funktionalität des gesamten Codes entwickeln. Auch wenn jede integrierte Funktion getestet wird, ersetzt TDD nicht die Notwendigkeit einer abschließenden Qualitätskontrolle und von API-Tests. 

• Erhöhter Aufwand: TDD erfordert, dass Programmierer zusätzlich zu ihrem Produktionscode auch eine große Suite von Tests verwalten. Die Wartung von Testcodebasen erfordert eine bestimmte Menge an Ressourcen und kann die Gemeinkosten erhöhen. 

• Geringere Effizienz: TDD verbessert zwar nachweislich die Produktivität, kann aber auch die Projektentwicklung verzögern, da bei der Erstellung und Implementierung jeder neuen Funktion weitere Schritte hinzukommen. 

• Erhöhte Einrichtungszeit: TDD verlangt von den Entwicklern, dass sie geeignete Testumgebungen für ihren Code einrichten und pflegen. 

• Vernachlässigung des Gesamtdesigns: Obwohl TDD die Einfachheit des Codes und ein verbessertes Design fördert, kann eine zu starke Konzentration auf einzelne Komponenten zu einem weniger harmonischen Gesamtcode führen. Programmierer, die TDD verwenden, müssen wissen, wie sich ihre einzelnen Funktionsupdates integrieren lassen, wenn sie in die übergreifende Softwareanwendung kompiliert werden.