TDD
Test-Driven Development
Test zuerst schreiben. Failen lassen. Den einfachsten Code schreiben, der den Test passieren lässt. Refactoren. Wiederholen.
Test-Driven Development ist eine Disziplin, keine Methodik. Die Schleife: rot (failing Test schreiben), grün (einfachsten Code schreiben, der grün macht), refactor (sauber machen, ohne den Test zu brechen). Wörtlich umgesetzt produziert es Code mit hoher Testabdeckung und einer Zwangsfunktion gegen Over-Engineering. Die Disziplin zahlt sich nur aus, wenn diese Tests bei jeder Änderung laufen, weshalb TDD und CI/CD Geschwister sind, keine getrennten Anliegen.
Warum die meisten Teams behaupten TDD zu machen, es aber nicht tun: Den Test zuerst zu schreiben fühlt sich im Moment langsamer an. Der Compounding-Payoff (Refactor-Sicherheit, Regressionsschutz, Designdruck zu kleineren Einheiten) zeigt sich erst Monate später. Bis dahin hat das Team aufgehört, Tests zuerst zu schreiben, und sich eingeredet, es habe nie einen Unterschied gemacht.
Beispiel, wo TDD seine Kosten verdient versus wo es Theater ist: Ein Payments-Reconciliation-Modul hat fiese Edge Cases (Teilrückerstattungen, Währungsrundung, Retries). Den failing Test zuerst zu schreiben zwingt dich, das erwartete Verhalten zu benennen, bevor der Code existiert, und die Suite fängt die Regression sechs Monate später ab, wenn jemand die Rundung „vereinfacht". Das ist TDD, das sich selbst bezahlt. Stell dem ein Wegwerf-Daten-Import-Skript gegenüber, das du in zwei Wochen löschst: Tests zuerst zu schreiben ist dort reiner Overhead. Die ehrliche Regel ist, die logik-lastige, teuer-falsch-zu-machende Code per TDD zu schreiben und den Rest nicht.
Der häufigste Fehler ist, Coverage als Ziel zu behandeln. Jag 90 % nach, und das Team schreibt Tests für Getter und Setter, um die Zahl zu treffen, während es die Integrationstests überspringt, wo die echten Bugs leben. Coverage ist ein nützliches Diagnostikum und ein schreckliches Ziel; es ist eine Metrik, die gegamed wird. Wavect nutzt TDD, wo es sich rechnet: Integrationstests für alles Geldförmige, Contract-Tests für alles Customer-Facing, BDD-artige Akzeptanztests, wo Produkt sie lesen können muss, Unit-Tests für nicht-triviale Logik. Wir testen die schweren Teile gut, nicht alle Teile gleich, und behandeln es als eine Praxis innerhalb einer gesunden Agile-Schleife, nicht als Häkchen.