Test Driven Development oder Unit Tests im nachhinein - Mehraufwand zeitlich?

[Pennytüte]

Hey,

wie ist denn der zeitliche Mehraufwand bei TDD? Vorteile gegenüber Unittests im nachhinein?

Interressant wäre auch, ob sich das durchsetzen lässt beim Chef und wenn dann wie? Herrscht doch immer Zeitdruck, oder nicht?!?

[stefan.macke]

Der zeitliche Mehraufwand durch Tests wird langfristig (!) durch weniger Aufwand bei der Weiterentwicklung und Fehlersuche meiner Erfahrung nach mehr als aufgehoben. Durch ein besseres Design steigt außerdem die Qualität der Software.

Konkrete Zahlen habe ich nicht. Es gibt aber viele wissenschaftliche Studien dazu. Ich stelle einfach mal 50% mehr Initialaufwand in den Raum.

[Whiz-zarD]

Unittests im Nachhinein zu entwickeln klappt meist auch nicht, da der Code dann der Code nicht testbar ist.
TDD ist zwar anstrengend aber es ist durchaus hilfreich, denn TDD führt dich nicht in die Versuchung, den Code irgendwie hinzuhacken. Der Code bleibt dann immer testbar. Wenn man die Unittests erst hinterher schreiben will, hat man dann oft ein Code, der nur sehr schwer testbar ist. Dann testet man nur die Schnittstellen nach außen. Wenn aber dann ein Fehler auftauchen sollte, ist man da erst mal mit dem Suchen beschäftigt, wo der Fehler überhaupt herkommt und je nach Komplexität kann es sehr Zeitaufwendig sein. 

Ich kenne es auch eigener Erfahrung, dass man die Entwicklungskosten gerne niedrig halten möchte und daher gerne auf Unittests verzichtet werden, weil Unittests Geld kosten und von Unittests hat der Kunde nichts aber das Geld, was man hier investiert, spart man später bei der Pflege des Codes. Ich selber arbeite an einem unwartbaren Monstrum, wo die Entwickler an vielen Stellen im Code sich nicht rantrauen, weil sie nicht wissen, welche Seiteneffekte entstehen könnten, wenn sie was am Code ändern sollten. Der Analyseaufwand steigt somit ins unermessliche. Wenn aber schon vornherein dafür gesorgt wurde, dass vernünftige Unittests geschrieben worden sind, kann man bei Änderungen sehr schnell herausfinden, ob noch alles so läuft, wie vorher.  

Zeitdruck herrscht immer, denn Zeit ist Geld. Geld, was der Kunde nicht ausgeben will und ich weiß, dass es schwer sein kann, den Chef davon zu überzeugen, aber das ist einfach eine Milchmädchenrechnung, wenn man meint, dass man beim Sparen an Unittests grundsätzlich Geld spart, nur weil das Produkt schneller zum Kunden kommt. Die ganzen Bugs, die der Kunde meldet und der enorme Zeitanstieg bei der Beseitigung der Bugs oder bei der Implementierung von Weiterentwicklungen, sieht oft der Chef nicht. Also muss man ihn dies vor Augen führen, welche Folgekosten so etwas hat.

[Goulasz]

TL;DR: Unit Tests nachher schreiben geht. Schön ist aber anders.

 

Längere Antwort: Schreibt man die Tests im Nachhinein, neigt man der Einfachheit halber dazu, "zu simple" oder ineffektive Tests zu schreiben. Baut man seinen Code direkt nach TDD auf, sind die Tests zum einen robuster und plausibler, zum anderen existieren sie nicht zu einem Selbstzweck, sondern um die Shipbarkeit deines Produktes zu gewährleisten.

Was sich in deinem Szenario anbietet, ist allgemein ein Refactoring mit dem Einführen der Tests zu verbinden. D.h. du guckst, ob du redundanten Code hast, den du auslagern kannst, setzt vielleicht sogar eine CI Pipeline(z.B. Jenkins) mit einem Duplicate Finder auf und implementierst in dem Rahmen deine Tests. Das geht, ist sinnig und in der Realität auch häufig der Fall. Leider sind es meiner Einschätzung nach immer noch die Mehrheit der Entwickler, die zum einen beim Entwickeln wenig auf robuste, modulare Architektur achten und auch Tests schreiben und zum anderen den Code regelmäßig im Pairing oder Dojo reviewen.

 

Gruß, Goulasz  

[arlegermi]

Einmal zum Thema "weniger Pflege-Aufwand". Da gibt's eine Übersicht in The Art of Unit Testing von Roy Osherove. Das ist keine wissenschaftliche Studie mit Allgemeingültigkeit, veranschaulicht die Sachlage aber recht schön:

 

Bearbeitet 13. September 2016 von arlegermi

[stefan.macke]

vor 15 Stunden schrieb Pennytüte:

wie ist denn der zeitliche Mehraufwand bei TDD?

Ich habe nochmal in meiner eigenen Masterarbeit nachgeschaut und diese Zahlen gefunden (leider schon etwas älter):

Zitat

 

Nagappan u. a. (2008, S. 297) kommen in ihrer Studie z.B. zu dem Ergebnis, dass sich die Entwicklungszeit für eine Software beim Einsatz von TDD um 15–25% verlängert und auch Lammi (2008, S. 3) berichtet von einer Verlängerung um 15–20%.

 

 

• Nagappan, Nachiappan ; Maximilien, E. M. ; Bhat, Thirumalesh ; Williams, Laurie: Realizing quality improvement through test driven development: results and experiences of four industrial teams. In: Empirical Software Engineering 13 (2008), Februar, Nr. 3, 289–302.
• Lammi, Grant: Test-Driven Development: Does writing software backwards really improve quality? Version: November 2008.