TDD als Erziehungsmaßnahme
In meinem ersten Eintrag im neuen Blog möchte ich mal etwas theory crafting betreiben und mich dem Thema TDD von einer etwas anderen Seite nähern.
Mittlerweile ist es 3 Monate her seitdem ich angefangen habe mich ernsthaft mit TDD zu beschäftigen. Eine zugegebenermaßen noch recht kurze Zeit. Trotzdem habe ich einige Interessante Erfahrungen gewonnen und Eindrücke gesammelt.
Zunächst einmal ist es eine gewisse Hürde Test first zu entwickeln. Es erfordert umdenken und das Umstellen gewohnter Entwicklungsprozesse. Das ist ein Fakt. Es erfordert Mühe und Einarbeitungszeit bis man wirklich den Prozess verinnerlicht hat und die Produktivität nicht mehr allzu viel leidet. Ein von Kritiker sehr häufig genutztes Argument: "Ich verliere sehr viel Zeit." Unstrittig ist jedoch wiederum, das automatisierte Tests heute zu einem de facto Standard geworden sind. Ohne automatisierte Tests kommt eigentlich kein Entwickler mehr aus. Dies führt in eine Zwickmühle: Der Entscheidung zwischen Produktivität auf der einen und Qualität auf der anderen. Es gilt also, den goldenen Weg zu finden, der das Ziel dem Kunden ein solides Endprodukt zur Verfügung zu stellen am besten Unterstützt. Denn: Hier drum geht es immer noch; dem Kunden das Projekt zu liefern das er möchte.
Eine Art damit umzugehen hat Thomas Bandt im Artikel über
"seinen TDD Alltag" beschrieben. Er testet (um es einmal auf das wesentliche zu reduzieren) nur noch Business Logik. Einfache alltägliche Dinge kann man einfacher in Integrationstest testen. Das gewährleistet notwendige Qualität und steigert die Produktivität.
Ralf Westphal wiederum vertritt (etwas überspitzt gesagt) die Meinung, dass es keine alternative zu komplett test first getriebener Entwicklung gibt. Seine Argumente sind so einfach wie überzeugend: Qualität, hoher grad von Automatisierung, Evolvierbarkeit. Diese unterschiedlichen Meinungen bieten viel Diskussionsstoff. Ich möchte hier gar nicht so darauf eingehen, was nun der bessere Weg ist.
Nichts ist so wertvoll, wie ErfahrungObgleich diese Diskussion sehr spannend ist und es natürlich auch richtig ist diese zu führen, bin ich sicherlich nicht der einzige, der das Gefühl hat, dass das Thema ein zu hohes Gewicht bekommt. TDD ist nur ein Tool zur Qualitätssteigerung. Wenn auch ein sehr effizientes. Es gibt noch andere Möglichkeiten, den meisten ist das natürlich bewußt. Gleichzeitig wird eine interessante Komponente von TDD übersehen: Der, ich taufe es mal, Erziehungseffekt. Wer sich intensiv mit TDD beschäftigt setzt automatisch viele Werte der
CCD um, als Beispiel: KISS. Das ist der erste positive Effekt, denn das CCD etwas gutes ist, darüber sind sich wohl alle einig. Gleichzeitig liefert uns korrekt durchgeführtes TDD doch aber auch ein Gefühl für Edge cases. Die Grenzfälle, die unser Programm oftmals vor schwierige Herausforderungen stellen. Mit der Zeit bedenkt man diese Fälle fast automatisch. Wie selbstverständlich werden die passenden Tests für diese Fälle mit erstellt. Darüber hinaus bekommen wir weiterhin ein Gefühl für Fehler.
Der typische Prozess Red-Green-Refactor zwingt das Programm ja zunächst zu "Fehlern". Zug um Zug implementiere ich Feature um Feature. Ich verinnerliche eine Thematik, die für den Entwicklungsprozess besonders wichtig ist.
Meine Beobachtung bzw. These ist nun folgende:
TDD verbessert meine Codequalität auch dann, wenn ich in einem späteren Projekt nicht mehr für jede Komponente einzelne Tests entwerfe, bzw. diese nicht test first entwickle, da ich durch TDD dazu erzogen wurde, bestimmte Fehlerfälle von vorneherein zu bedenken. Das Thema "Fehler" hat durch meine Erfahrungen einen anderen Stellenwert, es ist präsent. Natürlich geht auch dies mit der Zeit verloren, wenn man sich mit TDD für einen gewissen Zeitraum beschäftigt und es danach links liegen lässt. Auch der falsche Ansatz.
Wenn ich jedoch wo möglich TDD verwende, bin ich der festen Überzeugung, dass es auch die Projekte beeinflusst, wo aus welchen Gründen auch immer, kein TDD möglich oder gewünscht ist. Seien es nun die angesprochenen Preisgründe, Brownfield-Projekte, usw.
Meine bisherige Arbeit mit TDD spiegelt genau diese Sichtweise wieder. In meinem Projekt entwickle ich nicht nach TDD. Im Coding Dojo und zu Hause in meinen Projekten wiederum schon. Die während der mit TDD gemachten Erfahrungen kommen mir nun auch in den "business" Projekten zugute. Mein Code ist durch die implizite Anwendung von TDD besser geworden. Es ist nun keine Patentlösung TDD zu nutzen oder nicht zu nutzen. Doch finde ich zeigt dies doch auf, dass eben schon das nachdenken über den TDD Prozess mich in der Entwicklung ohne dieses Tool weiterbringen kann. Denn bei allem was man hier tut sollte die wichtigste Voraussetzung sein nachzudenken. Zu reflektieren wie sind meine Anforderungen, welche Werkzeuge brauche ich. Wie hole ich das Optimum aus diesem Projekt.
Und da bleibt für mich ein Fazit: Ich kann mich durch TDD dazu erziehen besseren Code zu schreiben, da sich meine Denkweise ändert. Selbst wenn ich TDD als Tool bei Projekten danach weglasse.
Mich würde an dieser Stelle wirklich interessieren wie Eure Erfahrungen bei diesem Thema sind und was ihr zum "Erziehungseffekt" zu sagen habt. Ist es schwachsinn was ich hier schreibe, entspricht es auch euren Erfahrungen, oder geht euch die ganze TDD Diskusison mittlerweile auf den Keks? Ich freue mich auf eure Kommentare.