Ich gebe gern zu, dass ich mich am Anfang eher schwer mit TDD getan habe. Der Grund dafür war, dass die Lehren die ich aus Büchern und Dojos zog, so gar nicht in meinen Entwickleralltag passen wollten. Kleine Umsetzungsschritte die nicht selten durch sinnlos scheinende Zwischenaktionen geprägt waren, haben mich fast zur Weißglut getrieben. Wenn ich dann TDD anwendete verzichtete ich also auf diese Schritte und fand mich nach einiger Zeit wiederum damit konfrontiert, dass meine Tests viel zu komplex wurden und die angeblichen Vorteile von TDD praktisch nicht präsent waren.

Ich glaube dies ist auch einer der Hauptgründe warum viele Leute wissen, dass TDD gut ist, in der Praxis aber nicht darauf zurück greifen. Auf der einen Seite steht der Mehraufwand den Baby-Steps machen und die Schwierigkeiten die ihre Findung im Alltag bereiten können. Auf der anderen Seite stehen die geringen Verbesserungen die man im Vergleich zu „normaler“ Testautomatisierung in der Praxis zu erhalten scheint. Ein Umstand der häufig aber darauf zurück zu führen ist, dass die Schritte eben zu groß gewählt wurden.

Es gibt also so einige Stolpersteine die den Einstieg erschweren und aus meiner Sicht nicht selten damit verstärkt werden, dass Anfängern sehr schnell die Triangulations-Baby-Step-Holzkeule  über den Schädel gezogen wird. Kann der Veranstalter eines Dojos zum Beispiel nicht glaubhaft erläutern warum wir uns zu einem Ziel hangeln (Triangulation) wirkt das Vorgehen im schlimmsten Fall deplaziert, realitätsfern und unsinnig aufwändig. Denn viele Katas laden den Ungeübten geradezu dazu ein sich in Endlosschleifen mit unnötigen Babysteps zu quälen, wenn der Code nicht kontinuierlich weiter entwickelt oder bei der Implementierung zu schnell zu viel gewollte wurde.

Dies ist ein Stück weit verständlich, denn letztendlich ist es ja der Sinn von Katas das richtige Maß bei der Umsetzung zu finden. Leider führt es meiner Meinung nach aber, wie bereits erwähnt, zu einer Abstumpfung gegenüber dem Konzept, wenn das dahinter liegende Konzept und die damit verbundenen Lernziele nicht im Vorfeld überzeugend vermittelt werden können.

Wenn wir also mit TDD beginnen, sollten wir uns bewusst machen welche verschiedenen Interpretationen und Ausprägungen Red-Green-Refactor zulässt. Denn dann können wir entscheiden wann und wie wir in der Praxis vorgehen sollen. Vor allem erkennen wir daran, warum bestimmte Dinge getan werden und wann sie evtl. den sprichwörtlichen Kanonen gleichen.

Welche Ausprägungen ich genau sehe und auch selbst anwende, ist in diesem Video beschrieben. [Werbung] Jenes ist Teil meines TDD Trainings bei Video2Brain, in welchem ich 6 Stunden über Testautomatisierung, Test Driven Development, Acceptance Test Driven Development und mögliche Frameworks aus der C# Welt spreche. [/Werbung]