Senior Java · Fachbereich

TDD & Test Quality Center

Teststrategie von schnellen Domänentests bis zu produktionsnahen Integrations- und Vertragstests. Nutze die Seite vor Review oder Freigabe: Wähle Prüfungen nach Risiko, dokumentiere Befunde und liefere nachvollziehbare Evidence statt einer pauschalen Bewertung.

Zur Übersicht

Arbeitsauftrag

Wann verwenden?

Wenn ein Risiko durch schnelle, aussagekräftige und wartbare Tests kontrolliert werden soll.

Nicht dafür verwenden

Nicht um Implementierungsdetails flächendeckend zu spiegeln oder Coverage als Qualitätsersatz zu verwenden.

Definition of Done

Testart passt zum Risiko; wichtige Grenzen und Fehlerfälle sind abgedeckt; Tests sind deterministisch und liefern verständliche Diagnose.

Testarten nach Risiko statt Gewohnheit wählen

TDD als Entwurfsfeedback nutzen

Flaky Tests und übermäßiges Mocking vermeiden

Testart nach Risiko

Test	Beantwortete Frage	Laufzeit	Nicht geeignet für
Unit	stimmt die fachliche Regel?	Millisekunden	Framework- und Datenbankverdrahtung
Integration	funktioniert der Adapter realistisch?	Sekunden	jede kleine Domain-Variante
Contract	bleiben Producer und Consumer kompatibel?	Sekunden	komplette Benutzerreisen
End-to-End	trägt der kritische Gesamtfluss?	Minuten	flächendeckende Fehlerdiagnose

Alle Kapitel

TDD auf Use-Case-Ebene

Der erste Test beschreibt beobachtbares Verhalten. Danach wird nur so viel Struktur erzeugt, wie für verständliche Fachlogik erforderlich ist.

Refactoring schließt jeden Zyklus ab. Ohne Refactoring wird TDD zu einer reinen Test-vorher-Technik.

JAVA

@Test
void rejectsOrderWithoutLines() {
    var command = new CreateOrderCommand(CustomerId.random(), List.of());

    assertThatThrownBy(() -> useCase.create(command))
            .isInstanceOf(EmptyOrderException.class)
            .hasMessageContaining("Position");
}

Testpyramide als Risikomodell

Viele schnelle Tests schützen Fachlogik. Weniger Integrations- und End-to-End-Tests prüfen reale technische Verträge. Die genaue Form richtet sich nach der Architektur.

Ein Kafka-Consumer benötigt andere Schwerpunkte als ein reiner Berechnungsdienst.

TEXT

Fachliche Regel            -> Unit Test
Application Use Case       -> komponentennaher Test
SQL / Mapping              -> Test mit echter Datenbank
HTTP-Vertrag               -> Contract Test
Broker-Verhalten           -> Integrationstest
kritischer Geschäftsfluss  -> wenige End-to-End-Tests

Architekturtests

ArchUnit oder ähnliche Regeln machen Abhängigkeitsrichtungen ausführbar. Regeln sollten wichtige Architekturabsichten schützen und nicht jede Paketbenennung zementieren.

JAVA

classes()
    .that().resideInAPackage("..domain..")
    .should().onlyDependOnClassesThat()
    .resideInAnyPackage("java..", "..domain..");

Praxisartefakt · Risikobasierter Testplan

Risiko: Doppelte Zahlung nach Retry des Checkout-Aufrufs.
Unit: Idempotenzschlüssel wird fachlich korrekt bewertet.
Integration: Payment und Idempotency Record werden atomar gespeichert.
Contract: Retry liefert denselben stabilen API-Vertrag.
Störungstest: Timeout nach Provider-Antwort erzeugt keine zweite Belastung.