Tests und Qualität
Testentstehung, Fitness Functions und Qualitätsrisiken.
Tests und Qualität
Layered
Die Referenz nutzt Domain-, Application-, Persistenz-, REST- und Architekturtests. ArchUnit schützt die Schichten. Qualitätsprofile umfassen Coverage, Mutation, statische Analyse, Formatierung und SBOM. Die Teststrategie folgt der bereits definierten Architektur.
TDD-First
Tests sind nicht nur Verifikation, sondern Entstehungsmechanismus. Akzeptanztests geben den äußeren Vertrag vor, Use-Case-Tests treiben Fachverhalten, Adapter Contract Tests sichern technische Implementierungen. Refactoring-Chronik und Test-Smell-Audit zeigen, wie Tests selbst verbessert wurden.
DDD
Aggregate Tests prüfen Invarianten und Ereignisse. Application-Smoke-Tests prüfen Commands, Queries, Ports und Transaktionen. Integrationstests prüfen Published Language, ACL, Outbox, Inbox und Process Manager. Architekturtests verhindern Context-Importe und schützen Domain-Unabhängigkeit.
Tatsächlicher Stand
| Variante | Testquellen | Testcode-Zeilen | direkt verifizierte Szenarien | teilweise | nicht implementiert |
|---|---|---|---|---|---|
| Layered | 23 | 724 | 20 | 3 | 13 |
| TDD-First | 26 | 385 | 27 | 1 | 8 |
| DDD | 17 | 261 | 11 | 8 | 17 |
Die Zahl der Testzeilen ist nicht mit Testqualität gleichzusetzen. TDD-First verwendet zusätzlich wiederverwendbare Testhilfen und viele schmale Produktionsklassen. DDD fokussiert im aktuellen Stand tief auf drei Core Contexts, während Supporting Contexts absichtlich fehlen.
Typische Testkopplung
| Risiko | Layered | TDD-First | DDD |
|---|---|---|---|
| Controller- und Service-Mocking | mittel | bewusst reduziert | gering im Domainkern |
| Tests gegen Implementierungsdetails | mittel | zentrales Refactoring-Thema | bei Aggregate-Interna möglich |
| langsame Integrationssuite | mittel | über Contract Tests kontrolliert | hoch bei vielen Contextflüssen |
| falsches Sicherheitsgefühl durch Coverage | möglich | durch Mutation und Test-Smell-Audit adressiert | durch Invarianten- und Contract-Nachweise adressiert |
Empfehlung
Coverage ist nur ein Warnsignal. Für alle Varianten sind entscheidend: beobachtbare Akzeptanzszenarien, belastbare Invarianten, wenige fragile Mocks, Adapterverträge und automatisierte Architekturgrenzen.