TDD (Test Driven Development) – eine gute Idee?

Aktuell werden wir Zeuge eines interessanten Disputs, den einige bekannte Software Architekten öffentlich über soziale Netze austragen.

Worum geht es?

Nicht zuletzt getrieben durch agile Vorgehensweisen, die häufiges Ausliefern von Software fordern, haben automatisierte Software-Tests an Bedeutung gewonnen. Die Idealvorstellung ist, dass nach jeder Änderung auf Knopfdruck in sehr kurzer Zeit (Sekunden bis wenige Minuten) feststeht, ob die Applikation noch immer alle Requirements erfüllt. Beim Test Driven Development (TDD) geht man sogar soweit, dass man vor der Implementierung erst einmal die automatisierten Tests schreibt, so dass der Implementierungsfortschritt auch direkt an den Testergebnissen abgelesen werden kann.

Diese Herangehensweise war bislang als „best practice“ akzeptiert und wurde kaum in Frage gestellt, auch wenn in der Realität dieses Ziel meist nur für einen kleinen Teil der Applikationen erreicht wurde.

Remember, though, that automated crap is still crap

Nun hat unlängst James Coplien, der in der Community aufgrund seiner Arbeiten zur Pattern einen hohen Bekanntheitsgrad besitzt, einen Artikel mit dem Titel „Why Most Unit Testing is Waste“ veröffentlicht. Darin hinterfragt er die Sinnhaftigkeit von TDD und rät zu einer Reduzierung der automatisierten Tests zugunsten von Zusicherungen (assertions) im Programmcode.

TDD is dead. Long live testing.

Diese Kritik wurde von David Heinemeier Hansson, dem Entwickler von Ruby on Rails, aufgegriffen. In seiner Keynote zur diesjährigen RailsConf 2014 und in einem Blogbeitrag beklagt er insbesondere eine zu starke Fixierung auf schnell ausführbare Unit-Tests, die zwangsläufig dazu führt, dass langsame Teile der Implementierung (z.B. Datenbankzugriffe) separiert und bei den Tests nur simuliert werden.

„Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that’s ’slow‘.“

M.a.W.: Die Architektur der Software leidet darunter und nimmt durch die Ausrichtung auf schnelle Ausführbarkeit von Unit-Tests Schaden.

You can quickly and easily clean the code without fear

Natürlich gibt es auch gut begründete Gegenstimmen, die die Vorzüge von TDD unterstreichen. Einer der bekanntesten Verfechter ist Robert C. Martin, ein Mitunterzeichner des agilen Manifests. In einer direkten Antwort auf Hansson (in der er auffälligerweise vermeidet, den Namen seines Widersachers zu erwähnen) stellt er noch einmal den zentralen Grund für TDD heraus:

„If you have a test suite that you trust so much that you are willing to deploy the system based solely on those tests passing; and if that test suite can be executed in seconds, or minutes, then you can quickly and easily clean the code without fear.“

Wer schon einmal erlebt hat, wie ein großes Softwaresystem schrittweise unwartbar wird, weil keiner mehr den Mut hat, an zentralen Stellen Veränderungen vorzunehmen, kann dieses Argument gut nachvollziehen.

Fazit

Software Engineering ist nicht wie Mathematik – es gibt keinen Beweis, dass die eine oder andere Sicht die richtige ist. Hilfreich ist in jedem Fall, dass durch die Diskussion die Gründe für TDD noch einmal transparent werden. Die Vorgehensweise ist eben nicht alternativlos.