Über Sinn und Unsinn von Test Driven Development

Test Driven Development (Testgetriebene Entwicklung) ist ein heiß diskutiertes Thema. Prominente Authoren und Persönlichkeiten der Entwickler-Szene debattieren mitunter ziemlich hitzig über Sinn und Unsinn von TDD.

Die Diskussion geht mittlerweile weit darüber hinaus, ob man nun einen Test vor dem zu testendem Code schreibt oder nicht. Daher lohnt es sich, die Tragweite der Debatte zusammenzufassen und für sich die entsprechenden Schlüsse zu ziehen. Am Ende des Artikels fasse ich auch den aktuellen Stand der Studien zusammen, die sich wissenschafltich mit TDD befasst haben.

TDD ist mehr als nur das Schreiben von Tests

Die Befürworter betten TDD in einem Entwicklungsprozess ein, der Implikationen hat, die weit über das bloße Schreiben von Tests hinaus gehen. Kent Beck beispielsweise hat den Begriff „emergent Design“ im Rahmen von XP (eXtreme Programming) geprägt. Die Idee ist, dass das Design, also die Architektur eines Systems, implizit durch die Evolution des Codes während des TDD Zyklus hervorkommt (to emerge).

Robert C. Martin (Uncle Bob), ein weiterer Verfechter von TDD, hat mit seinem Begriff des „Software professionalism“ TDD als Voraussetzung für professionelle Software-Entwicklung festgelegt. Weiter hat er weitere Prinzipien definiert, die daran anknüpfen und ebenfalls umstritten sind.

TDD als Voraussetzung für Professionalität

Uncle Bob argumentiert in etwa wie folgt: Software ist heute überall. Software steuert unsere Autos, Flugzeuge, Herz-Lungen-Maschinen usw. Somit geben wir im Grunde täglich unser Leben in die Hände derer, die Software entwickeln. Folgerichtig muss Software von höchst professionell agierenden Menschen entwickelt werden. Er sagt: „ich möchte nicht, dass die Beschleunigungssteuerung des Gaspedals an meinem Auto von einem 23-jährigen um 2 Uhr Nachts bei Pizza und Cola ungetestet committed worden ist“ Weiter vergleicht er Entwickler mit Ärzten und fordert, dass so wie es eine Ärztekammer gibt, die sich bei Vertoßen einschaltet, es auch eine entsprechende Institution für Entwickler geben sollte, die im schlimmsten Fall jemandem die „Entwicklerlizenz“ entziehen kann. Wie wird man seiner Meinung nach ein professioneller Entwickler? Die Basis sieht er in der strikten Einhaltung von TDD.

TDD als Voraussetzung für gute Architektur

Einige TDD Verfechter sind der Meinung, dass TDD nicht primär zum Testen da ist, sondern dazu, die Architektur eines System hervorkommen zu lassen. Die Idee, die auch vom YAGNI-Prinzip (You Ain’t Gonna Need It) beeinflusst ist, basiert auf dem Gedanken, dass ein BUFD zu viel vorweg nimmt und viele Dinge beschreibt, die später nicht wirklich verwendet werden. Emergent Design dagegen ist minimalistisch und wird kontinuierlich zusammen mit dem Code (und den Tests) getrieben.

TDD als Garant für gute Qualität

Es ist zwar recht offensichtlich, wie wir aber sehen werdem trotzdem notwendig, es anzusprechen. TDD Befürworter sind natürlich davon überzeugt, dass TDD qualitativ hochwertigeren Code und somit auch qualitativ hochwertigere Systeme erzeugt. Die einfache Logik ist die, dass sich Entwickler mehr Gedanken über den zu schreibenden Code machen, wenn sie vorher einen Test schreiben. Weiter führt testbarer Code meistens zu einer besseren Anwendung von Prinzipien wie „Low Coupling – High Cohesion“, DRY, YAGNI, LoD, IoC und viele andere mehr.

Was sagen die Studien

Schauen wir und einmal die relevantesten Studien zum Thema TDD an:

Siniaaltos Paper – 2006

The empirical results reveal that an unwanted side effect can be that some parts of the code may deteriorate. In addition, the differences in the program code, between TDD and the iterative testlast development, were not as clear as expected.

Siniaalto M., Abrahamsson P. (2008) Does Test-Driven Development Improve the Program Code? Alarming Results from a Comparative Case Study. In: Meyer B., Nawrocki J.R., Walter B. (eds) Balancing Agility and Formalism in Software Engineering. Lecture Notes in Computer Science, vol 5082. Springer, Berlin, Heidelberg

Die IBM/Microsoft Studie – 2008

The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

Nagappan, N., Maximilien, E.M., Bhat, T. et al. Empir Software Eng (2008) 13: 289. https://doi.org/10.1007/s10664-008-9062-z

Mäkinen/Münch – 2014

Based on the results, prominent effects include the reduction of defects and the increased maintainability of code. The internal quality of code in terms of coupling and cohesion seem not to be affected so much but code complexity might be reduced a little with test-driven development. With all the tests written, the whole code base becomes larger but more source code lines are being covered by tests. Test code is faster to write than the code implementing the test but many of the studies report increased effort in development.

Simo Mäkinen and Jürgen Münch, University of Helsinki, Effects of Test-Driven Development: A Comparative Analysis of Empirical Studies

Bissis Metastudy – 2016

Results: In about 57% of the analyzed studies, the results were validated through experiments and in 32% of them, validation was performed through a case study. The results of this analysis show that 76% of the studies have identified a significant increase in internal software quality while 88% of the studies identified a meaningful increase in external software quality. There was an increase in productivity in the academic environment, while in the industrial scenario there was a decrease in productivity. Overall, about 44% of the studies indicated lower productivity when using TDD compared to TLD.
Conclusion: According to our findings, TDD yields more benefits than TLD for internal and external software quality, but it results in lower developer productivity than TLD.

Bissi, Wilson & Neto, Adolfo & Claudia Figueiredo Pereira Emer, Maria. (2016). The Effects of Test Driven Development on Internal Quality, External Quality and Productivity: A systematic review. Information and Software Technology. 74. 10.1016/j.infsof.2016.02.004.

Capers Jones‘ Daten

Die vorherigen Studien geben ein ähnliches Bild ab: TDD bringt etwas mehr als TLD, erzeugt aber einen gewissen Mehraufwand, der sich in einer verminderten Entwickler-Produktivität manifestiert. Es ist gar nich so einfach, Studien zu finden, die besagen, dass TDD nicht empfehlenswert ist. Die Gegner von TDD, allen voran James Coplien, berufen sich dafür auf die Daten von Capers Jones aus seinem Buch Programming Productivity. Die Daten belegen nicht direkt, dass TDD schlecht oder besser ist als TLD. Vielmehr besagen Jones‘ Daten, wie sich verschiedene Testmethoden auf das Finden und Beheben von Defects auswirken.

Removal Step Efficiency
Lowest Modal Highest
Formal Design Inspections 35% 55% 75%
Modeling for Prototyping 35% 65% 80%
Field Testing 35% 50% 65%
Informal design review 30% 40% 60%
Formal code inspections 30% 60% 70%
Integration Test 25% 45% 60%
Functional Test 20% 35% 55%
Code Desk Check 20% 40% 60%
Design Doc Desk Check 15% 35% 70%
Unit Test 10% 25% 50%
Total 93% 99% 99%

Programming Productivity, 1986, Table 3-25, p. 179

In einem Paper von 2012 des selben Authors ergibt sich ein ähnliches Bild. Unit Testing schneidet eher bescheiden ab.

Removal Step Efficiency
Formal Inspections 93%
Static Analysis 55%
System Test 36%
Functional Test 35%
Component Test 32%
Unit Test 32%
Desk Check 27%
Prototyping 20%
Acceptance Tests 17%
Regression Tests 14%
Total 99.96%

“Software Defect Origins and Removal Methods,” Draft 5, 28 December 2012, http://www.ifpug.org/Documents/JonesSoftwareDefectOriginsAndRemovalMethodsDraft5.pdf

Es verwundert schon ein wenig, dass die meisten Studien eher Vorteile bei TDD sehen, zwei Authoren (Siniaalto und Jones) aber eher Nachteile oder zumindest keine Vorteile „gemessen“ haben möchte. Ein möglicher Grund hierfür liegt vielleicht darin, dass Capers Jones‘ Daten nicht unbedingt TDD so messen, wie es von modernen Befürworter definiert wird. Ein weiterer Aspekt ist, dass es keine weiteren Studien zu geben scheint, die die Daten von Jones bestätigen.

Zusammenfassung

TDD ist nach wie vor ein Thema, dass hoch emotional diskutiert wird. Die Studienlage scheint zu bestätigen, dass TDD grundsätzlich die Qualität steigert, die Produktivität aber zumindest initial mindert. In weiteren Artikel werden wir uns mit Alternativen zu TDD beschäftigen und weitere Testmethoden vorstellen.

Share your thoughts