TDD-Techniken-Katalog
Der Red-Green-Refactor-Zyklus (siehe Einführung) ist der äußere Rahmen - aber wie man von Rot nach Grün kommt, ist keine einzelne feste Rezeptur. Diese Seite katalogisiert die konkreten Techniken, die in diesem Projekt bewusst unterschiedlich je nach Situation eingesetzt werden, mit Fundstelle im Code. Ziel: nicht mechanisch immer denselben Handgriff zeigen, sondern die tatsächliche Bandbreite von TDD in der Praxis.
| Technik | Kurzerklärung | Wann sinnvoll | Fundstelle |
|---|---|---|---|
| Obvious Implementation | Die korrekte Lösung ist auf den ersten Blick klar - direkt so implementieren, kein Umweg über eine Attrappe. | Bei trivialen, offensichtlichen Fällen (einfache Zuweisung, direkte Delegation). Risiko: wenn man sich irrt, merkt man es erst beim naechsten Testlauf - deshalb nur bei wirklich einfachen Faellen. | Customer.verify()/reject() (Zustandszuweisung), Money.add() erste Fassung |
| Fake It ('Til You Make It) | Erst eine fest einprogrammierte, offensichtlich "unechte" Antwort liefern, nur um schnell Grün zu erreichen. | Wenn unklar ist, wie die echte Lösung aussehen soll, oder um das Test-Setup selbst zuerst zu validieren. Wird durch Triangulation zur echten Implementierung gezwungen. | geplant: erster Test in accounts-service (Deposit), siehe TDD-Katalog |
| Triangulation | Einen zweiten Testfall mit anderen Werten ergänzen, der eine Attrappe zwingt, durch echte Logik ersetzt zu werden. | Wenn eine einzelne Beispiel-Implementierung mehrdeutig waere. | Money.of (negativer Betrag erzwingt echte Validierung statt Attrappe) |
| Transformation Priority Premise | Bei mehreren moeglichen naechsten Code-Aenderungen die einfachere Transformation bevorzugen (Konstante → Variable → Ausdruck → ... vor Schleife/Rekursion). | Um Zwischenschritte so klein wie moeglich zu halten. | Money.add (zunaechst ohne Waehrungspruefung gruen, dann Wächter ergaenzt statt beides auf einmal) |
| Outside-In / London School (mockistisch) | Am aeusseren Rand beginnen (z. B. Anwendungsfall- oder Saga-Test), Kollaborateure zunaechst mocken, Implementierung schrittweise nach innen wachsen lassen. | Wenn der aeussere Ablauf/Vertrag eines Use-Case wichtiger ist als die interne Umsetzung, z. B. bei Orchestrierung ueber mehrere Ports. | geplant: payments-service-Saga (Phase 4), siehe TDD-Katalog |
| Inside-Out / Chicago School (state-basiert) | Vom fachlichen Kern (Value Objects, Aggregate) nach aussen entwickeln, mit echten Objekten statt Mocks wo moeglich. | Wenn die fachlichen Regeln selbst der schwierige/wichtige Teil sind. | common-domain (Money, AggregateRoot), customer-service-Domain-Schicht |
| Beispielbasiert → Parametrisierter Test (Refactor-Schritt) | Erst mehrere konkrete Einzel-Tests (@Test) schreiben, bis das Muster erkennbar ist - DANACH als Refactor-Schritt (Tests bleiben gruen) zu einem @ParameterizedTest mit Datentabelle verdichten. |
Wenn viele strukturell gleiche Faelle mit unterschiedlichen Werten entstehen (Grenzwert-Regelwerke). | CreditScorerTest in lending-service: fuenf Schuldendienstquoten-Faelle (a8c2a4b) → @ParameterizedTest mit @CsvSource (2af56e2) |
| Fitness Function statt Rot/Gruen-Paar | Eine Regel test-first formulieren, die aber schon beim ersten Schreiben erfuellt ist (kein erzwingbarer Rot-Zustand ohne die Regel absichtlich zu verletzen). | Architektur-Leitplanken (ArchUnit), die eine bestehende Disziplin nur zukuenftig absichern sollen. | CommonDomainPurityTest in architecture-tests |
Jeder Use-Case im TDD-Katalog referenziert (sobald umgesetzt), welche Technik(en) dort federführend eingesetzt wurden - meist mehrere kombiniert innerhalb eines Use-Case (z. B. Inside-Out für die Domain-Schicht, dann Outside-In für die Anwendungsschicht desselben Use-Case).