METHODE

TDD

Test-Driven Development

Test zuerst schreiben. Failen lassen. Den einfachsten Code schreiben, der den Test passieren lässt. Refactoren. Wiederholen.

Zuletzt geprüft: 2026-05-24 vonKevin Riedl wiki ↗

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.

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.

Wavect nutzt TDD, wo es sich rechnet: Integrationstests für alles Geldbezogene, Contract-Tests für Customer-Facing-Sachen, Unit-Tests für nicht-triviale Logik. Wir testen keine Getter und Setter. Coverage als Ziel ist eine Metric, die gegamed wird."

// FAQ

Häufige Fragen

Häufige Fragen

Mittel- und langfristig ja, am ersten Tag nein. Wer TDD nach einer Woche aufgibt, weil es sich langsam anfühlt, sieht den Refactor-Payoff nie. Wer drei Monate durchhält, traut sich Refactors zu, die Non-TDD-Teams nie machen.
Bei Throwaway-Prototypen, UI-Layout-Code und Glue-Code zwischen zwei stabilen APIs. Wer den Test für „componentDidMount" schreibt, verschwendet Zeit. TDD ist Disziplin, nicht Religion.
Schlechte Idee. Coverage wird gegamed, sobald sie zum Ziel wird. Tests, die nichts assertieren, treiben die Zahl hoch und prüfen nichts. Lieber Mutation-Testing als Coverage-Quote messen.