Schritt 1
Red
Verhalten beschreiben, Test ausführen und sicherstellen, dass er aus dem erwarteten fachlichen Grund fehlschlägt.
TDD-First
TDD-Strategie
Verbindlicher Outside-in-Entwicklungsweg für eine modular entstehende Java-21-Anwendung.
Java 21Outside-inRed–Green–RefactorKeine Vorabarchitektur
Red–Green–Refactor als Mikroschritt
Jeder fachliche Schritt beginnt mit einem beobachtbaren Fehlschlag und endet erst nach einem grünen Refactoringzustand.
Schritt 2
Green
Nur die kleinste fachlich korrekte Implementierung ergänzen. Keine vorsorgliche Zielarchitektur.
Schritt 3
Refactor
Namen, Duplikate, Verantwortlichkeiten und Grenzen verbessern, während das Verhalten unverändert grün bleibt.
Sechs Testebenen
Akzeptanztests
Gemeinsame Use Cases und Verträge von außen; keine internen Klassennamen.
Use-Case-Tests
Orchestrierung, Ergebnisse, Fehler und explizite ausgehende Interaktionen.
Domain-Tests
Invarianten und Zustandswechsel mit realen Fachobjekten, ohne Mocking.
Port Contracts
Ein Vertrag für frühe Fakes und spätere technische Adapter.
Adaptertests
Serialisierung, Mapping, Transaktionen, Broker-Header und technische Fehler.
Architekturtests
Konservieren erst dann Grenzen, wenn diese durch den Entwurf entstanden sind.
Test Doubles
| Double | Zweck | Regel |
|---|---|---|
| Dummy | Unbenutzter Parameter | Keine Logik und keine Verifikation |
| Stub | Gezielte Antwort | Keine Interaktionsprüfung |
| Fake | Vereinfachte echte Semantik | Bevorzugt für frühe Repositories und Uhren |
| Spy | Relevante Nachricht aufzeichnen | Nur beobachtbare ausgehende Wirkung |
| Mock | Konkrete Interaktion erwarten | Nur an echter äußerer Grenze, keine Kaskaden |
Nicht mocken Value Objects, Entities, Collections, fachliche Policies und den zu testenden Use Case.
Definition of Done
Rot nachgewiesen
Der Test war rot und der Fehlschlag hatte den erwarteten Grund.
Kleinster grüner Schritt
Nur notwendiges Verhalten wurde ergänzt.
Refactoring abgeschlossen
Struktur verbessert, Verhalten unverändert.
Grenzen begründet
Ports und Module entstehen aus realem Druck.
Historie erweitert
Entscheidungen, Checks und Refactorings werden oben ergänzt.
Vertrag rückverfolgbar
Jeder Schritt bleibt mit einem gemeinsamen Szenario verbunden.
Feingranulare die TDD-Fachkapitel
Walking Skeleton: erster roter Akzeptanztest und minimaler End-to-End-Pfad.
Customer: Registrierung, Identität, Builder und Repository-Fake.
Catalog: Preis, Aktivierung und Value-Object-Entwicklung.
Place Order: Positionen, Zustände und schrittweises Design.
Inventory: atomare Reservierung und Port Contracts.
Payment: Ablehnung, Retry, Idempotenz und Gateway-Grenze.
Billing und Fulfillment: Events und Kompensation.
Technische Adapter erfüllen dieselben Verträge wie die Fakes.
Test-Smells, Mutation, Modulgrenzen und Gesamtwerk.