Im Kontext der Softwareentwicklung bezeichnet Test Driven Development (TDD) die Strategie, vor der Entwicklung von Code bereits die Tests dafür zu erstellen und den eigentlichen Code erst danach zu entwickeln.12

Vorgehensweise

Ursprünglich vorgestellt wurde der Ansatz 2002 von Kent Beck, einem Mitentwickler des Extreme Programming, in seinem Buch “Test-Driven Development By Example”1.

Darin zeigte er die erfolgreiche Anwendung an verschiedenen Beispielen und erklärte dessen Zyklus “Red/green/refactor”, der die Entwicklung in drei Phasen einteilt, die immer wieder nacheinander ablaufen. Red und Green beziehen sich dabei auf die Farben für fehlgeschlagene (rot) und erfolgreiche (grün) Tests in vielen Entwicklungsumgebungen, Refactor3 beschreibt die Überarbeitung des Codes.

Der RGR-Zyklus

Das Projekt wird in kleine Funktionalitäten unterteilt, die nacheinander hinzugefügt werden sollen.

Schritt Aufgabe
Red Ein neuer Test für die Funktion, die ergänzt werden soll, wird geschrieben.
Weil das Programm die Funktion noch nicht beherrscht, muss er fehlschlagen.
Green Der Code wird umgeschrieben, bis der Testfall aus Schritt 1 erfüllt ist. Dabei wird nicht auf guten Stil (z.B. Kommentare, Vermeidung von Duplikationen) geachtet, wichtig ist die Funktion.
Refactor Jetzt wird der funktionierende Code überarbeitet. Danach soll er weiterhin funktionieren, aber auch die Richtlinien zu gutem Stil erfüllen, die im zweiten Schritt ignoriert wurden.

Uebersicht

Übersicht zum Vorgehen beim Test Driven Development4

Auswirkung von TDD auf den Projekterfolg

Zu der Auswirkung des TTD-Ansatzes auf den Erfolg von Projekten gibt es einige Untersuchungen, die aber wegen der individuellen Unterschiede zwischen Projekten nicht auf alle Projekte generalisierbar sind.

Eine Fallstudie bei IBM2 verglich die Ergebnisse eines Teams aus relativ unerfahrenen Entwickler:innen, die mit TDD arbeiteten, mit denen eines erfahreneren Teams, die das weniger formale Ad hoc-Testen5 verwendeten. Die Projekte waren ähnlich, die Produktivität wurde durch den Mehraufwand des TDD-Teams kaum beeinträchtigt, die Fehlerdichte nahm um 40% ab.

Eine andere Studie verglich die Ergebnisse von Studierenden an der Politecnico di Torino in einem Javakurs6. Die Experimentalgruppe verwendete TDD, die Kontrollgruppe schrieb die Tests erst nach dem Schreiben ihres Codes. Es wurde beobachtet, dass die Studierenden aus der TDD-Gruppe mehr Tests schrieben. Das zeigte eine Korrelation mit einer besseren Qualität der jeweils schlechtesten Ergebnisse der Gruppen, ergab im Durchschnitt der Gruppen aber keinen Vorteil. Die Ursache sehen die Autoren darin, dass es schwieriger ist, mit wenigen Tests alle wichtigen Funktionen abzudecken. Mit mehreren Tests ist das einfacher und weniger vom Können der Studierenden abhängig, das sich bei den Student:innen innerhalb der Gruppe unterscheidet. Die Korrelation “viele Tests” mit “bessere Mindestqualität” zeigte sich jedoch zwischen allen Studierenden, unabhängig von dem TDD- oder traditionellen Ansatz. Wegen verschiedener Effekte warnen die Autoren auch hier, die Ergebnisse zu generalisieren.

Synergieeffekte mit Extreme Programming (XP)

Der ursprüngliche Entdecker des Konzepts TDD, Kent Beck, spielte auch eine wichtige Rolle bei der Entwicklung des Xtreme Programming (XP). In seinem Buch über TDD1 geht er deshalb auf Seite 217 noch speziell darauf ein, wie sich die Grundsätze dieser beiden Arbeitsweisen kombinieren lassen.

  1. Ein Problem beim Pair-Programming des XP kann sein, dass die Entwickler:innen versuchen, unterschiedliche Probleme zu lösen oder das Problem unterschiedlich interpretieren. Die Orientierung an Tests im TDD vermeidet das, sodass allen immer klar ist, woran sie gerade arbeiten sollen.
  2. TDD bietet mit seinen Tests sinnvolle Meilensteine, an denen das Konzept “Bei Müdigkeit aufhören” des XP gut umsetzbar ist.
  3. Auch die kontinuierliche Integration wird durch die klaren Durchläufe des RGR-Zyklus unterstützt.
  4. Das YAGNI-Prinzip7 des XP hilft, die Testfälle einfacher zu halten, umgekehrt werden auch keine unnötigen Funktionen eingebaut, wenn sie nicht zum Bestehen der Tests benötigt werden.
  5. Das Refactoring am Ende des RGR-Zyklus garantiert die Einhaltung der XP-Regeln (z.B. die Abwesenheit von Duplikaten).
  6. Wenn neue Funktionen bereits ausreichend getestet sind, ist es weniger risikoreich, sie bei Kund:innen bereits einzusetzen, was die Continuous Delivery8 erleichtert.

Siehe auch

Weiterführende Literatur

Quellen

  1. Kent Beck, “Test-Driven Development By Example” ↩ ↩2 ↩3

  2. L. Williams, E. M. Maximilien and M. Vouk, “Test-driven development as a defect-reduction practice,” 14th International Symposium on Software Reliability Engineering, 2003. ISSRE 2003., 2003, pp. 34-45, doi: 10.1109/ISSRE.2003.1251029. ↩ ↩2

  3. Refactoring - Wikipedia Artikel ↩

  4. Ursprüngliche Abbildung veröffentlicht von Xavier Pigeon unter CC BY-SA 4.0, Übersetzung ins Deutsche durch Ferdinand Eckl, veröffentlicht unter CC BY-SA 4.0 ↩

  5. Ad hoc-Testen - Wikipedia Artikel (englisch) ↩

  6. H. Erdogmus, M. Morisio and M. Torchiano, “On the effectiveness of the test-first approach to programming,” in IEEE Transactions on Software Engineering, vol. 31, no. 3, pp. 226-237, March 2005, doi: 10.1109/TSE.2005.37. ↩

  7. YAGNI-Prinzip - Wikipedia Artikel ↩

  8. Continuous Delivery - Wikipedia Artikel (englisch) ↩