Architekturtests, Quality Gates & CI/CD
ArchUnit, Enforcer, Dependency Checks, Contract Tests, Testcontainers, Coverage und Build-Pipeline.
Version 3QualitätCodeDiagramm
In dieser Datei
Quality Gates schützen Architektur
Gute Regeln werden automatisiert. Sonst gewinnen Zeitdruck und Copy-Paste. Architekturtests prüfen Modulgrenzen, Dependency-Regeln, verbotene Frameworks in der Domain und Namenskonventionen.
CI/CD als Lernsignal
Eine Pipeline soll schnell Feedback geben: Kompilierung, Unit Tests, Architekturtests, Integrationstests, Security Checks, Packaging und Deployment. Fehler müssen verständlich sein.
Nicht alles in einen Test werfen
Schnelle Tests laufen früh, teure Tests später. Contract Tests schützen Schnittstellen, Integrationstests prüfen Adapter, End-to-End Tests bleiben sparsam.
Entscheidungen
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, Logs, Metriken, Traces, Security und Rollback definieren. | Wie erkennt der Betrieb Fehler rechtzeitig? |
Ausführliche Beispiele
ArchUnit Regel
@Test
void domain_must_not_depend_on_frameworks() {
noClasses().that().resideInAPackage("..domain..")
.should().dependOnClassesThat().resideInAnyPackage(
"org.springframework..", "jakarta.persistence..", "jakarta.ws.rs..")
.check(importedClasses);
}
Pipeline-Skizze
stages:
- compile
- unit-test
- architecture-test
- integration-test
- dependency-scan
- package
- deploy-dev
Typische Stolperfallen
| Stolperfalle | Warum gefährlich |
|---|---|
| Architektur nur im Wiki | Regeln werden nicht eingehalten. |
| Zu langsame Pipeline | Teams umgehen Tests. |
| Security erst vor Release | Dependency-Risiken werden spät sichtbar. |