ADR-0001: TDD als verbindliche Entwicklungsmethode
Status
Akzeptiert, 2026-08-07
Kontext
Dieses Projekt ist explizit als Lernprojekt zu Test-Driven Development konzipiert (siehe Einführung in TDD). Es soll nicht nur ein funktionierendes Ergebnis liefern, sondern die Methode, mit der es entsteht, selbst nachvollziehbar und lehrbar machen — für Entwickler:innen und für Architekt:innen gleichermaßen.
Entscheidung
Jede fachliche Verhaltensänderung an Produktionscode wird nach dem Red-Green-Refactor-Zyklus entwickelt:
- Ein neuer Test wird geschrieben und läuft nachweislich fehl (Compile-Fehler oder
Assertion-Fehler) — eigener Commit
test(<scope>): [RED] .... - Die minimale Produktionsänderung, die den Test grün macht — eigener Commit
feat(<scope>): [GREEN] .... - Optionale Strukturverbesserung ohne Verhaltensänderung, Tests bleiben grün — eigener Commit
refactor(<scope>): ....
Ausnahmen (reine Konfiguration, Test-Infrastruktur, teilweise Architekturtests) sind explizit in Einführung in TDD, Abschnitt "Was wird NICHT per TDD getestet", benannt.
Konsequenzen
Positiv
- Jede Zeile Produktionscode ist durch mindestens einen vorher geschriebenen Test motiviert — kein spekulativer Vorratscode.
- Die Commit-Historie wird zum didaktischen Artefakt (siehe Commit-Historie als Lernpfad).
- Design-Rückkopplung erfolgt sofort: ein schwer zu testender Anwendungsfall zeigt sich, bevor er in Produktion ist (siehe TDD für Architekten).
Negativ / Trade-offs
- Deutlich mehr Commits als in einem konventionellen Projekt üblich — für ein Team-Projekt außerhalb eines Lernkontexts würde man vor dem Merge typischerweise squashen.
- Höherer initialer Zeitaufwand pro Feature gegenüber "schnell mal draufloscoden" — zahlt sich laut der zugrundeliegenden Literatur (Beck, XP) erst über die Projektlaufzeit durch weniger Regressionen und leichteres Refactoring aus, was sich in einem kurzlebigen Lernprojekt nicht vollständig demonstrieren lässt.
Alternativen erwogen
- Test-After (Tests nach der Implementierung): verworfen, weil er den in Einführung in TDD beschriebenen Design-Effekt nicht liefert und für ein TDD-Lehrprojekt am Thema vorbeiginge.
- BDD mit Cucumber/Gherkin: verworfen zugunsten deutscher, verhaltensbeschreibender Testmethodennamen direkt im Code — spart eine zusätzliche Übersetzungsebene, siehe TDD für Architekten, Abschnitt "Bezug zu ATDD/BDD".