Test-Driven Development: effiziente Softwareentwicklung
Letzte Aktualisierung am 30 März 2023 um 10:42 am
3,00/5Test-Driven Development wird beim Design und der Entwicklung neuer Softwareprodukte eingesetzt. Dieses Konzept ist nicht neu, ist aber in der heutigen Zeit aktueller denn je. Bereits im Jahr 2002 stellte Kent Beck diesen neuen Ansatz der IT-Welt vor, bei dem intensives Testing in den Entwicklungsprozess aufgenommen wird. Davon versprach er sich ein schnelleres Entwickeln mit weniger Fehlern. Wie genau Test-Driven Development (TDD) funktioniert, zeigen wir Ihnen im folgenden Artikel.
Ein Überblick zum Thema Test-Driven Development
Bereits seit den Anfängen der Softwareentwicklung wurde das Developer Testing bei der Entwicklung eines neuen Computerprogramms genutzt. Jedoch fand dieser Prozess des Testens von der Programmierung des Quellcodes separat statt. Die Programmierer befassten sich mit der Erstellung des Quellcodes eines Programms und die Tester prüften die Software. Eine direkte Zusammenarbeit fand nicht statt.
Kent Beck sah das Potenzial, das sich hinter dem Testing verbarg, Softwarelösungen wesentlich schneller und effizienter umzusetzen. Seine Kommentare und Ideen zum Extreme Programming und zum Test-First-Ansatz wurden schnell bekannt. Er veränderte den Entwicklungsprozess dahingehend, dass die Programmierer zuerst einen Test geschrieben haben. Dieser wurde getestet. Erst nachdem das Testprogramm erfolgreich angenommen wurde, begannen die Entwickler mit der Erstellung des eigentlichen Quellcodes, dem Produktivcode. Die First-Test-Methode fand so viel Anklang, dass Sie heute auch bei anderen Designparadigmen zu finden ist.
Das Testen während der Entwicklung eines neuen Produktes koppelt sich direkt an die unterschiedlichen Entwicklungsstufen. Nur auf diese Weise kann eine neue Software kreiert werden, die so gut wie fehlerlos auf dem konkurrenzreichen Markt gelauncht wird. Grobe Fehler im Nachhinein auszubügeln ist zeitintensiv und prestigeschädigend, weshalb die Methoden das Test-Driven Development in vielen Bereichen Einzug gehalten haben.
Wie funktioniert Test-Driven Development?
Die Entwicklung einer neuen Software findet immer in Teilabschnitten statt. Schritt für Schritt stellen Entwickler die einzelnen Komponenten zusammen. Dabei läuft das Test-Driven Development inkrementell ab. Jede kleine Veränderung oder Zusatzfunktion wird getestet. Nach bestandenem Test integrieren die Entwickler diesen neuen Teil in den Quellcode.
Der große Vorteil, Unit-Tests und der Test von einzelnen Funktionen und Features nimmt in der Regel relativ wenig Zeit in Anspruch. Fortschritte sind dadurch schnell sichtbar. Der Entwicklungsprozess in kleinen Schritten folgt den drei Gesetzen des Test-Driven Development.
Zyklus 1
In dieser Testphase dauern die Zyklen in der Regel nicht länger als 30 Sekunden.
- Schreiben Sie zuerst einen Test, bevor Sie am Code für das Release-Produkt arbeiten.
- Schreiben Sie nur so viel Code, wie Sie für einen fehlgeschlagenen Test benötigen.
- Erstellen Sie nur so viel Code, dass der eigentlichen Testfall und dessen Bestehen erreicht wird.
Zyklus 2: der Red-Green-Refactor
Der sogenannte Red-Green-Refactor dauert meist mehrere Minuten und wird nach den ersten sehr kurzen Testphasen des Zyklus 1 eingesetzt.
- Sie schreiben den Test. Sollte der Test fehlschlagen, markieren Sie diesen rot.
- Danach schreiben Sie den Produktivcode und integrieren ihn in das System. Wird der Test bestanden, so wird dieser Schritt grün markiert.
- Der Code wird Schritt für Schritt erweitert. Dabei schreiben Sie Testfälle und die entsprechenden Codebestandteile. Den Zyklus des Refactoring durchlaufen Sie so oft bis die Software verständlich und effizient aussieht. Testen Sie dabei jede Codezeile. Ungetestete Zeilen können im späteren Verlauf zu Problemen führen.
Zyklus 3: der Specific-Generic-Zyklus
Im Rahmen dieser Testphase testen Sie die einzelnen Module. Ziel ist, die Anforderungen der geplanten Software zu erreichen.
Zyklus 4: der Primary-Zyklus
Dieser Zyklus zeigt die Grenzen der einzelnen Module auf. Diese Grenzen resultieren aus der Software Architektur und den festgelegten Regeln. Ziel dieser Phase ist das perfekte Ineinandergreifen aller Module und Komponenten der Software, sowie eine klare Struktur.
Organisatorische Aspekte im Test-Driven Development
Die Integration des Entwicklerteams in den Betrieb der Software bringt einige Vorteile mit sich. Die Programmierer sind viel stärker am Erfolg des Produktes interessiert. Regelmäßiger Erfahrungsaustausch mit den Kollegen führt zu einer schnelleren Lösung möglicher Probleme und steigert das Qualitätsniveau der Tests.
Für Neueinsteiger der TDD Methode empfiehlt sich das Pair Programming. Zwei Programmierer arbeiten zusammen an einem Bildschirm. Ein Mitarbeiter, der bereits Erfahrungen im Bereich des Test-Driven Development besitzt, führt den neuen Kollegen in die Materie ein. Kontinuierliche Kommunikation führt automatisch zu besseren Tests und Codes. Dabei ist natürlich die Unterstützung durch das Management für maßgebliche Erfolge unabdingbar.
Technische Aspekte
Jeder Unit-Test sollte aus technischer Sicht separat erfolgen. Im Falle von Abhängigkeiten werden sogenannte Mock-Objekte eingesetzt. Auf diese Weise sind die Tests äußerst resistent gegenüber Änderungen. Die Modul-Tests sollten schnell auszuführen sein. Zu lang dauernde Tests können dazu führen, dass die Entwickler eher darauf verzichten.
Eine gute Strukturierung der Tests erleichtert das Befolgen und zeigt deren großen Nutzen auf. Hier kommt die Triple-A-Regel zum Tragen: Arrange – Act – Assert. Zuerst wird die Umgebung initialisiert. Daraufhin wird das gewünschte Verhalten ausgelöst und mit dem Soll-Ist-Vergleich abgeschlossen.
Das Entwicklerteam sollte hier zu einer einheitlichen Namenskonvention finden. Idealerweise wird der Name aus diesen 3 Punkten zusammengestellt: Name des Tests, Testumgebung und erwartetes Ergebnis.
Am Ende jedes TDD-Zyklus steht das Refactoring des Test- und des Produktivcodes. Eine einheitliche Codierung ist ausschlaggebend für Übersichtlichkeit und somit Schnelligkeit in der Entwicklung des Quellcodes neuer Software.
Methodische Aspekte
Wie oft Sie Tests durchführen, sollten Sie bereits am Anfang des Projektes bedenken. Je kürzer und kleiner die Veränderungen, desto öfter können Sie Tests durchführen. Gerade die Unit-Tests sollten Sie regelmäßig realisieren.
Je weiter fortgeschritten der Prozess ist, desto weniger Tests finden in der Regel statt. Dafür steigt die Komplexität der Tests an. Die Überprüfungen dauern dadurch auch wesentlich länger. Einige Fehler können Sie mit einfachen Unit-Tests nicht entdecken. Gerade wenn es sich um das Zusammenspiel verschiedener Modulen handelt. In dieser Entwicklungsphase eignen sich Integrationstest sowie User-Acceptance-Tests. Letztere zielen auf die Gebrauchstauglichkeit ab. Bei den komplexen Tests sollte das Teammanagement sehr genau auswählen, welche Tests wann durchgeführt werden.
Was ist Extreme Programming?
Als Extreme Programming (XP) wird eine agile Form der Softwareentwicklung bezeichnet. Markante Merkmale und Werte dieser Arbeitsform sind:
- Kommunikation
- Einfachheit
- Mut
- Feedback
- Qualität
- Lernen
- Respekt
Mit diesen Werten im Hinterkopf werden Anwendungen entwickelt, mit denen die Nutzer vollauf zufrieden sind. Die Kosten für Änderungen halten sich dann in der Regel in Grenzen. Dabei wird auf bestimmte Techniken der Softwareprogrammierung gesetzt.
- Stetige Reviews und Test
- Durchgängiges Design und Redesign
- Kontinuierliches Feedback
- Kurze Releasezyklen
- Starke Integration des Kunden und des Auftraggebers
Diese Methode eignet sich vor allem für Projekte, die immer neuen Änderungen unterliegen. Dadurch können Sie Kosten besser kontrollieren und Termine leichter einhalten.
Vorteile der Verwendung von Test-Driven Development
Die Vorteile des Test-Driven Development gegenüber herkömmlichen Entwicklungsmethoden liegen eindeutig auf der Hand.
- Die Qualität der Software ist generell auf einem sehr hohen Stand.
- Die entwickelte Software weist wenige Fehler auf und muss nicht so häufig gewartet werden.
- Das Aufdecken von Fehlern und mögliche Wartungsarbeiten sind viel schneller und wesentlich einfacher zu realisieren.
- Der Code selbst zeichnet sich durch einfache und verständliche Angaben aus, die einer klaren Struktur folgen.
- Unnötige Codebestandteile werden vermieden, was zu schlanken Quellcodes führt.
Martin Fowler und sein Einfluss auf Test-Driven Development
Martin Fowler zählt zu den einflussreichsten Köpfen in der agilen Softwareentwicklung. Der Autor und Referent hat die Softwarearchitektur und all seine Komponenten zu seinem Wirkungsbereich erklärt. Im Speziellen befasst er sich mit objektorientierter Analyse und Design, UML, Entwurfsmuster und der agilen Softwareentwicklung.
Bereits seit den frühen 1980er Jahren arbeitet Fowler in der Softwarebranche und hat seitdem fünf Bücher zum Thema Softwareentwicklung herausgebracht und war einer der ersten Unterzeichner des Manifests zur agilen Softwareentwicklung. Dieses Manifest beruft sich auf die 4 Leitsätze:
- Individuen und Interaktionen sind mehr als nur Werkzeuge und Prozesse
- Funktionierende Software ist mehr als nur eine umfassende Dokumentation
- Zusammenarbeit mit dem Auftraggeber ist mehr als nur eine Vertragsverhandlung
- Reaktion auf Veränderungen ist mehr als nur das Abarbeiten eines Plans
Aus diesen 4 Leitsätzen erschließen sich die 12 agilen Prinzipien:
- Der Kunde wird zufriedengestellt mit früher und kontinuierlicher Lieferung von wertvoller Software.
- Agile Prozesse verwenden Veränderungen zum Wettbewerbsvorteil des Kunden auch spät in der Entwicklungsphase.
- Die Lieferung funktionstauglicher Software erfolgt in kurzen Zeitabständen.
- Zusammenarbeit von Entwicklern und Experten erfolgt auf täglicher Basis.
- Mitarbeiter-Motivation, welche das Umfeld und die gewünschte Unterstützung erzeugt, die zur Arbeitsbewältigung notwendig ist.
- Informationsaustausch von Angesicht zu Angesicht.
- Das wichtigste Fortschrittmaß ist die Funktionsfähigkeit der Software.
- Nachhaltige Entwicklung dank eines gleichmäßigen Arbeitstempos der Entwickler, Kunden und Benutzern.
- Technische Exzellenz und gutes Design stehen immer im Fokus.
- Einfachheit.
- Selbstorganisierte Teams entwerfen die besten Anforderungen, Ideen und Architekturen.
- Steigerung der Effizienz durch Selbstreflexion des eigenen Verhaltens der Teams.
4 Tipps für ein effizientes Test-Driven Development
Die Unit-Tests werden als die wichtigste Vorbedingung für alle Unternehmen gesehen, die TDD in ihre Entwicklungsprozesse aufnehmen wollen. Damit die Implementierung reibungslos funktioniert, sollten Sie einige Punkte beachten.
Test-Driven Development bei einem Bestandscode
Möchten Sie bei einem bereits existierenden Code TDD anwenden, könnten einige Probleme entstehen. Hier muss das Entwicklerteam entscheiden, ob der aktuelle Code überhaupt testbar ist und wie viel Refactoring notwendig wird, um TDD zu realisieren.
Wurde der Bestandscode geschrieben, ohne die Idee der Testbarkeit zu berücksichtigen, ist es sehr schwierig, in diesem Fall TDD anzuwenden. Sollte der Mitarbeiter, der den Code erstellt hat, eventuell nicht mehr im Unternehmen arbeiten und haben sich die abhängigen Bibliotheken geändert, übersteigt der Wartungsaufwand den Nutzen.
Ist er Bestandscode bereits in der Anwendung und funktioniert, so ist hier die beste Option, den Code so zu belassen, wie er ist. Sollte Änderungen oder Fehlerbehebungen notwendig werden, so lassen sich diese neuen Elemente mit der Methode des TDD erstellen.
Test-Driven Development bei Microservices
Software Architekturen, die auf Microservices basieren, zeigen wesentlich mehr Abhängigkeiten und eine höhere Komplexität auf als traditionelle Application-Stacks. Die Testumgebung kann sich in diesem Fall schwierig gestalten, da mit den Abhängigkeiten viel Mocking und Stubbing verlangt wird. Erprobte TDD-Verfahrensweisen können am besten auf die Microservices angewendet werden, wenn diese als einzelne Module wahrgenommen werden.
Hier lassen sich auf API-Ebene automatisierte Tests entwickeln, welche die geforderten Definitionen enthalten, die zu positiven Testergebnissen führen. Der Begriff API bedeutet Application Programming Interface. Für solche API-Testlösungen gibt es mittlerweile verschiedene Anbieter.
Alle müssen an Bord sein
Die Umsetzung des Test-Driven Development mit all seinen Tests kann gerade bei kleineren Unternehmen an die Grenzen der verfügbaren Ressourcen stoßen. Die Verwendung der TDD-Methode auf der API-Ebene kann helfen, die begrenzten Ressourcen optimal zu nutzen. API-Tests sind spezielle Softwaretests, welche die Schnittstelle einer Applikation auf Zuverlässigkeit und Funktionalität überprüft. Dies wird zum Beispiel mithilfe von Integrationstest erreicht.
Sie erreichen, dass nicht nur die Entwickler die Testphasen durchführen, sondern auch Analysten und Tester ihr Wissen beitragen können.
Der Einsatz von Softwarelösungen, die auf die Umsetzung einer simulierten Funktionalität spezialisiert sind, helfen bei der Erstellung und dem Ausführen von Tests, bevor der Produktivcode geschrieben wird. Bei der Entwicklung einer effizienten Strategie helfen Agenturen und Firmen, die branchenspezifisches Wissen und jahrelange Erfahrung vereinen.
Bereicherung des TDD mit BDD
Während das Test Driven Development sind auf das Bestehen von Tests konzentriert, fokussiert sich BDD (Behavior-Driven Development) auf eine verhaltensgetriebene Entwicklung. Der Code wird in diesem Fall nicht geschrieben, um einen Test zu bestehen, sondern um ein erwartetes Verhalten zu implementieren.
Die Idee des Behavior-Driven Development wurde schon in der Vergangenheit ansatzweise umgesetzt. In Zusammenhang mit TDD bietet BDD eine Chance, technische Hürden weiter zu reduzieren und ein neues Niveau zu erreichen. Automatische Tests können aus dem Feature File erstellt werden, was zur Verringerung der technischen Komplexität führt, die beim Schreiben des Code benötigt wird. Normalerweise werden dafür Entwickler-Ressourcen in Anspruch genommen.
Fazit
Die Nutzung der Methoden des Test-Driven Development führt bei der richtigen Umsetzung zu schlankem und einfachem Code. Einige Programmierer schreiben keinen Quellcode mehr, ohne vorher einen Testfall für die Codezeile zu erhalten. Das hat langfristig nur positive Auswirkungen, da es generell den Umfang des Quellcodes reduziert. Das Projekt selbst wird schneller und effektiver umgesetzt und die Veröffentlichkeitszyklen werden kürzer.
Im Fokus stehen die Ziele und die Funktionalität der Software. Die detaillierte Dokumentation der Test ermöglicht es auch im Nachhinein Veränderungen vorzunehmen. Programmierer, die nicht an der Entwicklung beteiligt waren, finden sich schnell in den Quellcode ein und können Wartungsarbeiten und Fehlerbehebungen vornehmen. TDD erfordert wahrscheinlich Informatiker und Programmierer mit hohem Erfahrungswert. Doch die Investition in die menschlichen Ressourcen lohnt sich allemal. Suchen Sie noch nach den richtigen Partnern, die Ihnen bei der Entwicklungsstrategie unter die Arme greifen, dann finden Sie diese jetzt bei Sortlist.
