In welcher Beziehung steht TDD zu Planung? Beruhigender Weise in einer guten! Auch wenn Kent Beck von der „verrückten Idee spricht, zuerst einen Test zu schreiben“ – ohne Planung, auch wenn TDD als Design Methodik beschrieben wird, so ist TDD doch immer nur eine Spielart der Implementierung – also keine Spielart der Projektplanung, keine Technik für die Anforderungserfassung, kein Weg um Architektur zu definieren.
Planung und Architektur
TDD als Implementierungsvorgehen prägt natürlich auch die Architektur. Statt Architektur zu definieren, kann sie kontinuierlich entwickelt werden, da (Unit)Tests ein Sicherheitsnetz spannen. Aber die Entscheidung zwischen Domänenmodell oder Table Module, wie entfernte Systeme miteinander gekoppelt werden, wie Session State behandelt wird, auf welche Art Persistenz umgesetzt wird und wie Beispielsweise ViewModell, Domänenenmodell und Datenmodell miteinander interagieren – all das ist nicht TDD und braucht gegebenenfalls Planung.
Verzögerte Planung
Auch nicht jedes Problem auf Implementierungsebene lässt sich mit Ad-Hoc Tests lösen. Die Umsetzung der meisten Bauteile, Komponenten, Module erfolgt besserer Weise auch nicht ohne Konzeption, möchte man einwerfen! Die Antwort von TDD bleibt immer noch „test first“, nicht „plan first“. Hintergrund ist die Überlegung, dass TDD als Designtechnik dabei hilft die Anforderungen der API zu definieren und durch interaktives spielen eine höhere Qualität erreicht wird. Explorativ und evolvierend sind die passenden Schlagworte. Der Denkprozess erfolgt in kleinen Erkenntnisschritten, vielleicht gar nicht so anders als mit Papier und Bleistift. Kommt man nun tatsächlich an eine Hürde die nicht zu nehmen ist, so lässt sich das Denken wieder auf Papier verschieben oder in ein Brainstorming in der Gruppe oder durch eine Umsetzung aus dem Lehrbuch ersetzen. Die Planung wurde jedoch verzögert und zwar bis zu dem Moment, wo sie wirklich benötigt wurde! Fortschritt ist nicht verloren, denn die hochwertige API steht dank TDD zu großen Teilen schon. Bedürfnisse und Anforderungen der API sind erlebt und buchstäblich entwickelt.
Dogmatik
Die Idee, erst mit der API zu spielen und sich nicht in der Planung von Implementierungsdetails zu verschwenden, ist eine Vorgehenstechnik, die erstaunlich erfolgreich ist, aber sie ist nicht die einzige. So ist das Schreiben von Akzeptanz- und Verhaltenstests sinnvoll. TDD schließt andere Arbeitsmodi nicht aus, so ist es denkbar an einem Tag die Methodik mehrfach zu wechseln und auch muss TDD nicht für alle Problemlösungen eingesetzt werden oder passt auch für jedes Problem. TDD sollte jedoch zum Entwickler Repertoire gehören und oft zum Einsatz kommen, da es sich um eine einfache, effiziente und zielführende Vorgehensart handelt.
