HUMAN-READABLE-TEST-CONTRACT-MODEL

Modell für menschenlesbare Testverträge#

Zweck#

Tests sind ausführbare Spezifikationen. Sie müssen für Menschen verständlich ausdrücken, welches Verhalten, welche Invariante oder welches Risiko sie schützen.

Verbindliche Regeln#

1. Jeder Testname beschreibt Ausgangslage, Handlung und erwartetes Ergebnis.
2. Wichtige Tests erklären in einem kurzen Kommentar, welche fachliche Invariante sie schützen.
3. Unit-, Component-, Integration-, Contract- und E2E-Tests bleiben unterscheidbar.
4. Happy Paths allein genügen nicht.
5. Schreibende Use Cases prüfen mindestens Validierung, Autorisierung, Nebenläufigkeit, Transaktion, Grenzwerte, Unicode und Audit-/Outbox-Folgen, soweit anwendbar.
6. Regressionen erhalten einen dauerhaft verständlich benannten Test.
7. ⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. Manifests verknüpfen Use Cases mit Testkategorien und Testpfaden.
8. Testberichte verwenden fachliche Beschreibungen statt ausschließlich technische Funktionsnamen.

Testkategorien#

• happy-path
• validation
• boundary
• authorization
• security
• concurrency
• transaction
• idempotency
• unicode-i18n
• audit
• outbox
• regression
• fuzz-property

Stabilitätsprinzip#

Ein Test schützt nicht nur eine Implementierung, sondern eine explizite Erwartung. Wird die Erwartung geändert, muss zuerst die zugehörige Architektur- oder Requirement-Entscheidung angepasst werden.