Vorteile der testgetriebenen Entwicklung: Wichtige Statistiken & Studien
In diesem Artikel werte ich einige Statistiken und Studien zur testgetriebenen Entwicklung aus, um zu verstehen, wie sie eingesetzt wird, welche Vorteile sie bietet und vor welchen Herausforderungen Teams bei diesem Ansatz stehen.
Traditionell verläuft der Prozess der Softwareentwicklung linear. In den letzten Jahrzehnten haben sich jedoch agile Methoden immer mehr durchgesetzt (bis zu 87% der Teams folgen einem agilen oder agil-ähnlichen Ansatz), sodass die Softwareentwicklung begonnen hat, unterschiedliche Methoden zu kombinieren, die die Anforderungen und Besonderheiten des Projekts berücksichtigen.
Die testgetriebene Entwicklung (TDD) ist eine der Methoden, die im agilen Softwareentwicklungsbereich Aufmerksamkeit auf sich gezogen hat.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
In einer von der Institute of Electrical and Electronics Engineers veröffentlichten Forschungsarbeit sagen die Autoren Yahya Rafique und Vojislav Misic, dass „Testgetriebene Entwicklung (TDD) zu den Grundpfeilern der Extreme Programming (XP) Entwicklungsmethodik zählt“ (Quelle).
Dem Mann, dem die Entwicklung von TDD zugeschrieben wird, wird nachgesagt, er habe „im Jahr 2003 festgestellt, dass TDD zu einfachen Designs ermutigt und Vertrauen schafft“ (Quelle). Dennoch gibt es weiterhin Fragen zu den Behauptungen bezüglich der Produktivität und Qualität von TDD.
Wir haben uns etwas Zeit genommen, um die neuesten TDD-Statistiken zusammenzutragen und die Behauptungen zu überprüfen.
Dieser Artikel beginnt mit einer Definition des TDD-Konzepts und erläutert, wie es sich vom traditionellen Ansatz unterscheidet. Anschließend betrachten wir einige Statistiken, die die Behauptungen bezüglich TDD entweder bestätigen oder widerlegen.
Was ist testgetriebene Entwicklung?
Testgetriebene Entwicklung ist ein Ansatz, bei dem ein Test geschrieben wird, bevor der Softwareentwickler den Produktionscode erstellt, der den Test erfüllt. Die Grundidee dieser Methode ist es, dem Code-Autor Zeit zu geben, um über das Design oder die Anforderungen nachzudenken, bevor funktionaler Code geschrieben wird.
TDD-Prozess
- Den Test schreiben: Bei TDD beginnt jede neue Funktion mit dem Verfassen eines Tests. Der Programmierer muss die Spezifikation und die Anforderungen der neuen Funktion verstehen. Dafür muss er sich mit User Stories und Anwendungsfällen befassen, um das Ziel des neuen Codes, den er entwickelt, zu verstehen.
- Test schlägt fehl: Nachdem der Programmierer den Test geschrieben hat, führt er diesen aus. Da es noch keinen Code zur Umsetzung gibt, wird der Test fehlschlagen. Das bestätigt, dass das automatisierte Testframework korrekt funktioniert und schließt aus, dass der neue Test immer bestanden würde, weil er fehlerhaft ist.
- Code schreiben: Jetzt weiß der Programmierer, dass die Funktion entsprechend dem Design funktioniert. Er schreibt nun den Code, der den Test bestehen lässt. Der Code muss dabei nicht perfekt sein oder den Test einwandfrei bestehen – das spielt keine Rolle. Vom Entwickler wird nicht erwartet, dass er mehr programmiert, als für die vom Test abgedeckte Funktionalität erforderlich ist.
- Tests ausführen: Da die Funktion wie vorgesehen funktioniert, kann der Programmierer bei jeder neuen Codeversion ein Testmanagement-Tool einsetzen, um den Test erneut durchzuführen, und erhält so die Bestätigung, dass sein jüngstes Update das zuvor implementierte Feature nicht zerstört hat.
- Code umgestalten: Mit wachsender Codebasis muss im TDD-Prozess ständig gründlich aufgeräumt werden. Da der Hauptfokus des Programmierers in den vorangegangenen Schritten auf dem reinen Coden lag, sorgt dieser Schritt für Effizienz. Die interne Struktur des Quellcodes wird verbessert, während dessen äußere Merkmale unverändert bleiben. Hier können Duplikate entfernt und neue Funktionen ergänzt werden.
- Wiederholen: Die oben genannten Schritte werden automatisch wiederholt, um sicherzustellen, dass alle TDD-Zyklen alle Features abdecken.
Unterschiede zwischen TDD und traditioneller Entwicklung
Um TDD zu verstehen, ist es sinnvoll, zu bestimmen, wie sich dieser Ansatz von traditionellen Programmiermethoden unterscheidet.
Der Hauptunterschied besteht darin, dass traditionelle Methoden einen linearen Ablauf verfolgen, während TDD in einem zyklischen Prozess abläuft.
Programmierer, die die traditionellen Testmethoden verwenden, beginnen mit der Erstellung des Codes und konzentrieren sich erst am Ende des Entwicklungsprozesses auf das Testen. Im Gegensatz dazu beginnt jemand, der das TDD-Modell (Testgetriebene Entwicklung) verfolgt, mit der Erstellung des Tests und entwickelt dann den Code, der den Test erfüllt. Dieser Ansatz teilt viele Prinzipien mit der Shift-left-Bewegung im Softwaretest.
Während sich der Programmierer bei der traditionellen Vorgehensweise zwar auf die Korrektheit des Codes konzentrieren kann, läuft er Gefahr, nicht alle Fehler im Code zu erkennen. Derjenige, der die TDD-Methode nutzt, arbeitet so lange am Code, bis dieser durch Refaktorisierung die Tests besteht. Dies geschieht so lange, bis der Code die gewünschte Funktionalität erreicht, ein Vorgang, der voraussichtlich zu weniger Fehlern führt.
Ist TDD langsamer oder schneller als die traditionelle Testentwicklung?
Bezüglich der Frage, ob TDD den Programmierprozess beschleunigt, gibt es unterschiedliche Statistiken aus verschiedenen Quellen.
Eine Fallstudie mit Microsoft- und IBM-Teams von Software-Ingenieuren kam zu dem Ergebnis, dass die „Teams bei der Anwendung der TDD-Technik eine um 15–35 % längere anfängliche Entwicklungszeit“ verzeichneten. Die Studie weist jedoch darauf hin, dass diese Zahlen „subjektiv von der Geschäftsleitung geschätzt“ wurden (Quelle).
Betrachtet man die Microsoft- und IBM-Studien aus der Perspektive der Qualitätsverbesserung, kann argumentiert werden, dass TDD auf lange Sicht Zeit spart, die sonst für das Beheben von Problemen benötigt würde. Die Teams bei Microsoft und IBM stimmten dieser Ansicht zu (Quelle).
Eine Studie, die sich auf die anfänglichen Wahrnehmungen erfahrener Fachleute bei der Nutzung von TDD konzentrierte, kommt zu dem Schluss, dass „nachdem anfängliche Schwierigkeiten beim Einstieg überwunden wurden und klar ist, wie man einen Test für eine noch nicht bestehende Funktion erstellt, die Teilnehmer mehr Vertrauen gewinnen, neue Features zu implementieren und Änderungen vorzunehmen, da sie von umfassender Testabdeckung profitieren“ (Quelle). Dies deutet darauf hin, dass sich die Dinge mit der Zeit verbessern.
Im Online-Veröffentlichungsportal Medium.com beschreibt der Programmierer und Autor von „Composing Software“ und „Programming JavaScript Applications“, Erick Elliot, wie TDD sein Leben verändert hat. Elliot stimmt zu, dass der Prozess zu Beginn langsam sein kann, sagt aber: „Irgendwann nach etwa zwei Jahren passierte etwas Magisches: Ich fing an, schneller mit Unit-Tests zu programmieren, als ich es je ohne sie getan habe“ (Quelle).
Es scheint, dass die Nutzung von TDD anfangs zu langsameren Abläufen führen kann. Betrachtet man jedoch den langfristigen Nutzen, kann die durch bessere Codequalität eingesparte Zeit die zu Beginn verlorene Zeit ausgleichen. Außerdem ist zu erwarten, dass erfahrene Programmierer mit TDD auch schneller werden.
Es gibt noch viele weitere Faktoren, die berücksichtigt werden sollten, wenn man die Zeit bis zu einem hochwertigen Ergebnis messen will. Mehr dazu gibt es in Niall Lynchs Folge im Podcast "The QA Lead" über die Messung von T2Q (Time To Quality).
Führt TDD zu weniger Fehlern?
In der obigen Diskussion wurde als ein Hauptvorteil von TDD hervorgebracht, dass es zu weniger Fehlern führt. Aber stimmen die Statistiken damit überein?
Die oben erwähnten Studien mit den Engineering-Teams bei Microsoft und IBM stellten fest, dass die „Fehlerdichte der vier Produkte vor ihrer Veröffentlichung um 40 % bis 90 % im Vergleich zu ähnlichen Projekten ohne TDD-Praxis gesenkt werden konnte.“ Konkret berichteten die IBM-Teams von einem Rückgang der Fehlerdichte um 40 %, während jene bei Microsoft einen Rückgang zwischen 60 % und 90 % meldeten (Quelle).
Stützen Statistiken zur testgetriebenen Entwicklung die Schlussfolgerung, dass TDD eine bessere Qualität liefert?
Basierend auf den Ergebnissen einer auf dem ersten Internationalen IEEE-Symposium 2007 in Finnland vorgestellten Studie berichten Maria Siniaalto und Pekka Abrahamsson, dass TDD nachweislich zu besserer Codequalität führt als Software, die ohne TDD entwickelt wurde (Quelle).
In ihrer Arbeit zitieren Siniaalto und Abrahamsson eine Studie, die in China durchgeführt wurde und zu dem Schluss kam, dass TDD die Prozessverfolgung und die Aufgabenschätzung verbessert. Dieselbe Studie kommt zu dem Ergebnis, dass „TDD auch das Einhalten konsistenter Praktiken und Richtlinien stärkt.“ Dies führt zu besserer Qualität mit weniger Fehlern. Außerdem konnten die Teams, die TDD nutzten, ihre Fehler schneller beheben (Quelle).
Eine unter Entwicklern durchgeführte Studie, die im Schnitt etwa zehn Jahre Berufserfahrung haben, untersuchte ihre Wahrnehmung beim Einsatz von TDD und zitiert einen Entwickler: „TDD hat mir geholfen, den Code zu verbessern und lesbarer zu machen.“ Ein anderer Teilnehmer berichtet, dass „TDD eine höhere Wartbarkeit ermöglicht“ (Quelle).
Fördert TDD ein einfacheres Design?
Boby George und Laurie Williams, beide tätig am Department of Computer Science der North Carolina State University, führten ein Experiment durch, bei dem 24 Programmierer in zwei Gruppen eingeteilt wurden: Eine verwendete TDD, die andere einen linearen Ansatz.
George und Williams berichten, dass von den Teilnehmern „92 % der Entwickler glaubten, dass TDD zu qualitativ hochwertigerem Code führt, 79 % dachten, dass TDD ein einfacheres Design fördert, und 71 % hielten den Ansatz für deutlich effektiv“ (Quelle).
Diese Statistiken zur testgetriebenen Entwicklung in Bezug auf die Qualität deuten stark darauf hin, dass TDD tatsächlich zu qualitativ hochwertigerem Code und einem einfacheren Design führt.
In einem Artikel, der vom kostenlosen Lernportal Guru99.com veröffentlicht wurde, sagt Kanchan Kulkarni: „TDD macht den Code einfacher und klarer. Es ermöglicht dem Entwickler, weniger Dokumentation zu pflegen“ (Quelle).
Ist es einfach, TDD-Design einzuführen?
Aus dem Experiment von George und Williams glaubten 56 % der professionellen Entwickler, dass es schwierig sei, sich auf eine TDD-Denkweise einzulassen, während 23 % angaben, dass das Fehlen einer vorgelagerten Designphase der Grund für diese Schwierigkeit sei. Insgesamt waren 40 % der Meinung, dass die Einführung von TDD schwierig ist (Quelle).
Diese Statistiken zur testgetriebenen Entwicklung hinsichtlich der Einführung zeigen, dass TDD als schwierig zu implementieren gilt.
Ist TDD überbewertet?
In einem auf Medium.com veröffentlichten Artikel benutzt Tylor Borgeson, der sich selbst als Full Stack Software Developer mit Interesse an Machine Learning, KI, Infrastruktur, DevOps und Agile bezeichnet, die Überschrift „Test-Driven Development is Overrated“. Dass er die Überschrift in Anführungszeichen setzt, zeigt jedoch, dass es sich nicht um eine eigene Aussage handelt.
Borgeson wendet sich anschließend an diejenigen, die behaupten, die Methode sei überbewertet und langsam, und sagt ihnen, dass die meisten Menschen, die diese Meinung vertreten, die Methode nicht lange genug angewendet haben. Am Ende seines Artikels schreibt er: „Nun üben Sie Testgetriebene Entwicklung, bis es nicht mehr weh tut“ (Quelle).
Wie geht es weiter?
Lernen Sie QA-Ansätze von Experten im The QA Lead Podcast
Melden Sie sich für den QA Lead Newsletter an, um unsere neuesten How-to-Guides und Podcast-Episoden zu erhalten
Tragen Sie sich auf die Warteliste für das QA Lead Online-Community-Forum ein, um Best Practices mit anderen QA- und Softwaretest-Experten zu teilen.
Wir freuen uns auf Sie!
