Gestern war ich bei Agile Saxony und habe über die unterschiedlichen Schulen des TDD gesprochen und wie sie sich auf unsere Arbeitsweise auswirken. Für mich besonders interessant war dabei die Diskussion am Ende meines Vortrages. Denn anscheinend war meine Vortragsweise etwas negativ konnotiert, wodurch ich eher skeptisch als überzeugt gewirkt haben muss. Ich war sehr übernächtigt, daher entschuldigung an dieser Stelle, wenn der Vortrag nicht die sonst übliche Qualität hatte.

Nichts desto trotz, habe ich selbst sehr viele Erkenntnisse aus eben jener Diskussion gezogen, denn sie hat einmal mehr gezeigt, dass der Einsatz von TDD sehr stark vom Einsatzgebiet abhängt. Wenn ich Applikationen habe, die fast nur UI an Frameworks bindet, dann komme ich mit dem klassischen TDD nicht weit. Hier bietet sich aber ATDD sehr gut an. Dieses ist aber wiederum nicht für Applikationen geeignet, die sehr von Algorithmen getrieben werden, dort bietet sich wiederum das klassische TDD an.

Letztendlich, und dies gillt es unbedingt noch einmal fest zu halten, vermischt man die einzelnen Ausprägungen in der Praxis sowieso. Die Frage ist für mich daher weniger wie man (A)TDD im speziellen einsetzt, sondern ob man seine Unit Tests durch automatisierte Systemtests ergänzt. Denn wenn TDD noch nicht im Team angekommen ist, dann braucht man die Einführung von ATDD fast nicht zu versuchen. Weil TDD kann ich auch allein verwenden, ohne auf andere Teammitglieder angewiesen zu sein. Wenn ich aber der einzige im Team bin der ATDD verwendet, scheitere ich sehr schnell, da die eigentlichen Vorteile kaum zum Tragen kommen und sich die Nachteile noch verstärken.

Vielen Dank also noch einmal an die gestrigen Zuhörer und die wirklich interessanten Unterhaltungen.