4Max/shutterstock.com

01. August 2014 / von Robert Lauer

TDD

erfolgreich

missverstehen

Die Debatte über Test-Driven Development ist wieder aufgelebt. Ursache waren diverse provokative Äußerungen von David Heinemeier Hansson (DHH). Daraufhin hat sich Martin Fowler der Sache angenommen und eine durchaus interessante Diskussion mit Kent Beck und David Heinemeier Hansson geführt.

So weit, so positiv. Erwartungsgemäß hat DHH aber auch viel Applaus von Bloggern bekommen, die das Thema im besten Fall nur oberflächlich verstanden haben – von diesen „Hab‘ ich doch schon immer gewusst“-Posts habe ich mal exemplarisch einen herausgegriffen, der mir besonders aufgestoßen ist.

Schon sprachlich ist der Post alles andere als gelungen. Es geht los mit dieser kuriosen Begriffsdefinition:

TDD are the initials of Test Driven Development. […] TDD is more than writing tests. TDD is about writing tests first before you write every single component of your project.

Gemeint ist wahrscheinlich das Richtige, aber der Text suggeriert, dass ich erst alle Tests schreiben muss, bevor ich eine Zeile produktiven Code schreibe. Das würde auch besser zum Folgesatz passen:

This leads to a series of inconveniences that discouraged many developers to embrace TDD.

Erst wasserfallartig alle (?) Tests zu schreiben, vermutlich auch noch mit einigen Verständnislücken, das wäre mir auch zu unbequem. Vielleicht ist auch das Schreiben eines kurzen, präzisen Tests vor der Entwicklung dem Autor schon zu unbequem. Nehmen wir zu seinen Gunsten an, dass er ständig mit häßlichen Altsystemen arbeitet, sodass TDD in seinem Kontext einfach sehr unbequem ist.

Im Folgenden finden sich viele andere missverständliche Passagen, aber ich will mal auf das Niggemeiern verzichten und nur inhaltliche Merkwürdigkeiten betrachten.

My main objection to TDD is that it is expensive. If you need to write tests for everything upfront, obviously your project will take more time or more developers to build it.

Völlig offensichtlich. Deswegen kommen auch alle Studien zum Thema zu sehr unterschiedlichen Ergebnissen. Die wahrscheinlich meistzitierte TDD-Studie (Nagappan et al.kommt zu dem Schluss, dass TDD-Projekte 15 bis 35 Prozent mehr Entwicklungsaufwand produzieren, dafür aber auch 60-90% weniger Fehler enthalten.

Obviously, writing tests ahead means that your project will take much longer to launch. Some defenders claim that the time you spend writing tests will pay up in the future if you break something. The fact is that you only break something if you change it or change its dependencies in a significant way. So if you fear that a change may break your project, write tests then right before you make those significant changes.

Die stillschweigende Annahme ist hier, dass ich (a) erst dann Fehler mache, wenn ich existierende Funktionalität erweitere, Refactorings durchführe etc., und (b) dass ich dann auch schon genau weiss, wo ich die Fehler mache, und genau für diese Aspekte dann Tests schreibe.

When the project goals change, at least part of the code becomes useless because it will no longer be used after the business goal change.

If you have written extensive tests for the code that will be dropped, the tests also become useless.

Korrekt, vielleicht muss ich manchmal Tests wegwerfen für etwas, was weniger lange gelebt hat, als ich erwartet hätte. Manchmal muss ich aber auch „Prototypen“ warten, die plötzlich in die Produktion überführt wurden, und nach zehn Jahren immer noch da sind.

Very often you need to change parts of the implementation without changing the outcome of your application. The outcome is the main thing to be preserved. If the outcome is broken, the means that were used to reach that outcome are possibly broken too. To arrive to that conclusion you do not have to test every little software component that implement the means.

Über die richtige Granularität von Tests kann man trefflich streiten – das exzessive Mocken und Stubben haben Martin Fowler, Kent Beck und David Heinemeier Hansson im Gespräch ja auch übereinstimmend kritisiert.

Fakt ist aber, dass man bestimmte Softwareeigenschaften – insbesondere Fehlerfälle – auf einer grobgranularen Ebene nicht mit vertretbarem Aufwand testen kann. Robert Binder verwendet in seinem Buch die Metapher, Münzen mit einem Boxhandschuh aufheben zu wollen. Wenn ich diese Fehlersituationen aber einfach nicht teste, teste ich gerade die Problemfelder nicht, wo ich auch bei manuellem Testen wahrscheinlich selten drüber stolpern werde. Wer auch immer diesen Ansatz verfolgt, entwickelt hoffentlich keine Medizinprodukte oder andere lebenskritische Systeme.

For many developers, spending too much time writing tests makes them feel much less productive because they need to spend much more time to see the outcome of their software.
This is why many developers do not like writing tests at all.

Korrekt, viele Entwickler schreiben nicht gerne automatisierte Tests. Das ist aber ein positivistisches Argument: Genauso hätten zu Zeiten von Ignaz Semmelweis viele Ärzte gesagt, dass sie sich nicht gerne die Hände waschen, um mal eine Metapher von Robert Martin aufzugreifen.

Außerdem ist das Schreiben von Tests vorher nach meiner Erfahrung immer deutlich komfortabler als hinterher (und sehr viel komfortabler als einen Monat oder gar ein Jahr später). Das mag jeder für sich beurteilen. Es fühlt sich nur merkwürdig an, so wie sich der Habitus des regelmäßigen Händewaschens in unserer Zivilisation vielleicht anfangs auch merkwürdig angefühlt hat.

Auf die Argumente, dass TDD „preachers“ zu dogmatisch sind, gehe ich hier mal nicht detailliert ein. Es gibt durchaus Leute, auf die das zutrifft, aber letztlich muss sich jede(r) ohnehin seine/ihre eigene Meinung bilden und einen Ansatz finden, der zur eigenen Persönlichkeit passt.

Ich kann hier nur dazu animieren, TDD mal in unterschiedlichen Entwicklungskontexten auszuprobieren und die Erfahrungen dazu mit anderen zu teilen!

 

Autor

Robert Lauer
Robert Lauer
Weitere Artikel

Das könnte Sie auch interessieren