Ich habe mir mal erlaubt, 8 Gründe für den Einsatz von TDD zusammenzutragen. Jeder, der noch bessere oder weitere Argumente kennt, ist herzlich eingeladen, diese Seite zu kommentieren.

  1. TDD macht schön.
    Ich kann das 100% bestätigen. Seitdem ich testgetrieben entwickle, habe ich besser getrennte, lose gekoppelte Komponenten, die so zusammenspielen, wie ich es mir von Beginn an vorgestellt habe und nicht, wohin die Implementierung mich getrieben hat.
  2. Test last funktioniert nicht
    Das ist m.M.n. richtig.
    Es gab von Bernd Schiffer und Johannes Link im Jahr 2010 einen Vortrag zum Thema TDD (s. Youtube), in dem Johannes feststellte, kein Projekt zu kennen, das mit Test last Strategie eine höhere Abdeckung als 60% erreicht und keiner der ca. 200 Teilnehmer konnte ihm widersprechen.
    Das ist auch meine Erfahrung und liegt unter anderem darin begründet, dass zum Teil nicht testbare Komponenten implementiert werden, für die das Erstellen von Tests einen inakzeptablen Zusatzaufwand bedeuten würde.
  3. TDD erlaubt mir separation of approaches.
    Erst mache ich mir Gedanken, was ich möchte und anschließend wie ich es tun kann und nicht gleichzeitig, was bei Straight forward Implementierung notwendig wäre. Ich kann mich also leichter fokussieren.
  4. TDD erzeugt technische Dokumentation in Echtzeit.
    Alle meine Tests bzw. Unit Tests sind ja eine hervorragende Dokumentation in der Sprache, die alle Entwickler sprechen, nämlich die Programmiersprache. Was will man als Entwickler mehr.
    Zudem ist diese Dokumentation nicht veraltet, solange die Tests grün sind.
  5. Mit TDD ist Refactoring jederzeit möglich.
    Zum einen ist Refactoring, also das Umbauen von Quellcode ohne die Funktionalität zu ändern zum Zwecke der Qualitätsverbesserung, integraler Bestandteil des TDD Zyklus.
    Zum anderen erzeugen die 100% Testabdeckung ein fundiertes Sicherheitsnetz für nachträgliche Änderungen, die aufgrund von neuerlichen Gesamtsichten, aktuellen Technologien und ähnliche unverschuldeten Gründe notwendig geworden sein kann.
  6. TDD schafft 100% Testabdeckung.
    Allen voran ist das ja das Hauptargument für TDD. Der sichere Weg zu einer vollständigen Abdeckung meines Codes durch Tests.
    Das man damit nicht 100%ige Sicherheit erhält, erläutert das Mutational Testing, aber es ist der richtige Weg.
  7. TDD funktioniert.
    Es gibt inzwischen einige Projekte, die als TDD Projekte unterwegs sind, und in ihrer Umsetzungsgeschwindigkeit keinem anderen Projekt hinterherhinken. Das spricht für sich.
  8. TDD relaxed.
    Zumindest in den Projekten, in denen ich und der Rest des Teams testgetrieben gearbeitet haben, waren wir alle ziemlich tiefenentspannt, wenn es um das Release oder Deployment neuer Funktionalität ging, weil wir uns aufgrund der hohen Testbadeckung unserer Sache sicher sein konnten.