Ü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 wissenschaftlich 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 nicht 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% | 25% | 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 | 93% |
“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.
