Autor
Andreas Havenstein
- LinkedIn:andreas-havenstein-3b4044181
Warum viele kleine Testschritte positiven Einfluss auf das Design der Software haben
Die testgetriebene Entwicklung ist ein wesentlicher Baustein für erfolgreiche agile Softwareentwicklung. Die Methode hat ihren Ursprung in Extreme Programming und durch sie sind Praktiken wie Continuous Integration und Continuous Delivery erst möglich geworden.
Der schnelle Überblick
Testgetriebene Entwicklung (Test-Driven Development, TDD) ist eine iterative Softwareentwicklungsmethode, die sich durch das Schreiben von Tests vor der eigentlichen Implementierung auszeichnet. TDD fördert sauberes Design, höhere Codequalität und frühe Fehlererkennung, indem es die Entwicklung von Anfang an durch Tests leitet.
TDD ist ein wesentlicher Bestandteil von Extreme Programming (XP) und ergänzt andere Praktiken wie Continuous Integration und Continuous Delivery. Es unterstützt Teams dabei, nur die tatsächlich benötigte Funktionalität zu entwickeln, und schafft Vertrauen in die Qualität des Produkts. Neugierig? Wir bringen Agile Developer Skills in Ihr Unternehmen.
Bei der testgetriebenen Entwicklung (engl. Test-Driven Development, TDD) werden Tests dazu benutzt, um die Softwareentwicklung zu steuern. Der Ablauf dieser Programmierung ist zyklisch:
Die Tests werden typischerweise mit dem XUnit-Framework in der gleichen Sprache wie der Produktivcode implementiert. Tests, die erfolgreich durchlaufen, werden durch einen grünen, nicht erfolgreiche durch einen roten Balken dargestellt. Man spricht daher vom "Red-Green-Refactor"-Zyklus.
Testgetriebene Entwicklung geht inkrementell vor. Jeder durchlaufene TDD-Zyklus reichert die Software um neue Fähigkeiten an - und das minutiös, denn jeder Zyklusabschnitt sollte nicht länger als ein paar Minuten dauern.
Die Tests noch vor den Komponenten zu schreiben, die man eigentlich testen möchte, ist sehr markant für TDD. Dies wird als Test-First bezeichnet und darum ist TDD keine Test-, sondern eine Designstrategie. Denn wird der Test zuerst geschrieben, so wird die Schnittstelle der zu testenden Komponente bereits benutzt, bevor sie tatsächlich existiert. Der Entwickler bekommt frühestmöglich Feedback, ob das Design auch verwendbar sein wird. Die Implementierung des produktiven Codes erfolgt erst, wenn ein Test vorliegt, der dies verlangt. Es soll dann genau soviel Code geschrieben werden, dass der Test erfolgreich durchläuft. Wird zu viel Produktivcode für einen Test geschrieben, dann entstehen nicht getestete Stellen, die beim Refactoring Probleme bereiten können.
Beim Refactoring werden die Tests und der Produktivcode gleichermaßen aufgeräumt. Ziel hierbei ist es, die Software einfach, redundanzfrei und verständlich zu gestalten. Diese Phase des TDD-Zyklus geht dem Zyklusanfang unmittelbar voraus: Um einen bestimmten Test zu schreiben, kann es notwendig sein, zuerst ein Refactoring an den anderen Tests oder dem Produktivcode vorwegzunehmen.
Der Zyklus ist überschneidungsfrei, jede Aktivität beim testgetriebenen Entwickeln lässt sich einem Abschnitt zuordnen. Es sollten keine Tests in Phase 2 und 3 und kein Produktivcode in Phase 1 und 3 geschrieben werden. Beim Refactoring wird das Verhalten des Codes nicht verändert, also dabei weder bei den Tests (Phase 1) noch im Produktivcode (Phase 2) etwas funktional verändert.
Prinzipien, die TDD vereint, sind die kontinuierliche Designverbesserung, einfaches Design und Test-First. TDD selbst ist eine Kerntechnik von Extreme Programming und damit Teil der agilen Softwareentwicklung. Es verspricht Qualitätssoftware und eine deutliche Aufwertung der Softwarearchitektur dank evolutionärem Design.
Zum Abschluss
Wartbare Qualitätssoftware:
Effektive und effiziente Erstellung der Software:
Interesse geweckt?
Software Crafting Techniken sind ergänzend zu gutem Software-Engineering nötig, um in einem agilen Team entwickeln zu können. Es geht darum, in kurzen Zyklen Wert zu schaffen und diesen möglichst schnell produktiv zu stellen, um Feedback von Endkunden einzuholen. Werden Sie ein exzellenter SW Craftman mit unseren Trainings:
Darüber hinaus bieten wir Unterstützung durch testerfahrenen agilen Entwickler:innen (mehr) und helfen Ihren eigenen Entwickler:innen dabei, Tests Gewinn bringender einzusetzen (mehr).
Über den Autor
Andreas Havenstein ist Trainer, Architekt und Softwareentwickler bei der it-agile GmbH in Hamburg. Seit vielen Jahren begeistert er sich für agile Methoden, testgetriebene Entwicklung und modulare, flexible Architekturen. Er hat eine Cloud-Migration begleitet und beobachtet gespannt, wie sich die Welt in Richtung Serverless bewegt.
Veröffentlichungen (u. a.):
Kennen Sie eigentlich schon it-agile?
Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.