85 lines
6.8 KiB
Markdown
85 lines
6.8 KiB
Markdown
# Abschlussbericht Arbeitspaket AP10 – Architekturtest
|
||
|
||
> **Bezug:** `docs/arbeitspakete/m1/AP10-architekturtest.md`
|
||
> **Bearbeiter:** Claude Code (claude-sonnet-4-6), Subagent
|
||
> **Datum:** 2026-04-20
|
||
> **Commit(s):** noch offen (Mensch committet nach Sichtung)
|
||
> **Status:** ✅ abgeschlossen
|
||
|
||
## 1. Zusammenfassung
|
||
|
||
ArchUnit 1.3.0 wurde als Test-Dependency aufgenommen und die Architekturtest-Klasse `de.gecheckt.asv.ArchitectureTest` mit vier Regeln (A–D) implementiert. Alle vier Regeln waren beim ersten Lauf **grün** — es wurden keine Verstöße gefunden. Zusätzlich wurde `src/test/resources/log4j2-test.xml` angelegt (E-02).
|
||
|
||
## 2. Umgesetzte Änderungen
|
||
|
||
- `pom.xml` — ArchUnit-Dependency `com.tngtech.archunit:archunit-junit5:1.3.0` (test scope) ergänzt
|
||
- `src/test/java/de/gecheckt/asv/ArchitectureTest.java` — neue Testklasse mit Regeln A–D (`@AnalyzeClasses`, `@ArchTest`)
|
||
- `src/test/resources/log4j2-test.xml` — Test-Log-Konfiguration angelegt (Root level WARN, Console/SYSTEM_ERR); Log4j2 bevorzugt diese Datei im Test-Classpath gegenüber `log4j2.xml`
|
||
|
||
## 3. Scope-Treue
|
||
|
||
| Scope-Punkt aus dem Arbeitspaket | Erfüllt? | Bemerkung |
|
||
|---|---|---|
|
||
| ArchUnit als Test-Dependency | ✅ | `archunit-junit5:1.3.0`, test scope |
|
||
| Vier Regeln A–D implementiert | ✅ | `ArchitectureTest.java` |
|
||
| `log4j2-test.xml` anlegen (E-02) | ✅ | Root level WARN, SYSTEM_ERR |
|
||
| Leere Testklassen prüfen und löschen | ✅ | Keine leeren Testklassen gefunden; `DefaultStructureValidatorTestAdditional` hat 4 aktive `@Test`-Methoden (bewusst behalten) |
|
||
| Keine neuen Produktionsklassen | ✅ | Kein einziger neuer `.java`-Produktionscode |
|
||
| Zyklische Abhängigkeits-Regeln (Scope OUT) | ✅ | Nicht umgesetzt |
|
||
| Coverage-/Mutation-Schwellen (Scope Out) | ✅ | Nicht umgesetzt |
|
||
|
||
**Wurde der Scope eingehalten?** Ja, vollständig.
|
||
|
||
**Wurden Dinge außerhalb des Scopes gemacht?** Nein.
|
||
|
||
## 4. Abnahmekriterien
|
||
|
||
| Abnahmekriterium aus dem Arbeitspaket | Erfüllt? | Nachweis |
|
||
|---|---|---|
|
||
| ArchUnit als Test-Dependency in `pom.xml` | ✅ | `archunit-junit5:1.3.0`, test scope, `pom.xml` |
|
||
| Vier Architekturregeln A–D implementiert und grün | ✅ | `Tests run: 4, Failures: 0, Errors: 0` in `de.gecheckt.asv.ArchitectureTest` |
|
||
| `log4j2-test.xml` unter `src/test/resources/` | ✅ | `src/test/resources/log4j2-test.xml` |
|
||
| Keine leeren Testklassen | ✅ | Alle Testklassen haben mindestens einen `@Test` |
|
||
| `mvn clean verify` grün, kein unerwartetes Log-Rauschen | ✅ | `BUILD SUCCESS`, 222 Tests, 0 Failures |
|
||
| Bericht dokumentiert erste Ausführung (rot/grün) | ✅ | Siehe Abschnitt 5 unten |
|
||
| Abschlussbericht unter `docs/arbeitspakete/m1/berichte/AP10-bericht.md` | ✅ | Diese Datei |
|
||
|
||
## 5. Build- und Teststatus
|
||
|
||
- `mvn clean verify`: ✅ grün (`BUILD SUCCESS`)
|
||
- Anzahl Tests: 222 gesamt (davon 1 Skipped — Windows-bedingter `fall5_dateiNichtLesbar_exitCode2` aus AP08); 4 neu in `ArchitectureTest`
|
||
- ArchUnit-Tests beim ersten Lauf: **alle 4 Regeln sofort grün** — keine Verstöße
|
||
- Log-Rauschen: Im Maven-Konsolenoutput erscheinen ERROR/WARN-Zeilen aus `CliRunnerOperationalErrorTest` (z.B. `Bedienfehler: Kein Argument übergeben`). Diese stammen vom SLF4J/Log4j2-Logger innerhalb des zu testenden `CliRunner.run()`-Aufrufs. Sie sind fachlich korrekt und erwünscht. Die `log4j2-test.xml` (Root=WARN) unterdrückt INFO/DEBUG-Rauschen; ERROR-Zeilen aus Negativ-Tests bleiben sichtbar — das ist das dokumentierte Verhalten aus E-02. Der Build ist sauber.
|
||
- Warnungen beim Build: die üblichen maven-shade-plugin-Überlappungswarnungen (unveränderter Stand seit AP02)
|
||
|
||
### Erster Lauf der 4 Regeln
|
||
|
||
Alle vier ArchUnit-Regeln waren beim ersten Lauf sofort grün. Das bestätigt:
|
||
- **Regel A (Log4j2-Sichtbarkeit):** `CliRunner` verwendet nur SLF4J (`org.slf4j`), kein direktes Log4j2. `LoggingConfigurator` liegt korrekt in `adapter.out.logging`. `Main` in `bootstrap` verwendet keine Log4j2-Typen direkt.
|
||
- **Regel B (Domain-Reinheit):** Keine Domain-Klasse referenziert Adapter oder Bootstrap.
|
||
- **Regel C (Application-Reinheit):** Keine Application-Klasse referenziert Adapter oder Bootstrap. (Die Testklassen wurden von `@AnalyzeClasses(..., importOptions = ImportOption.DoNotIncludeTests.class)` ausgeschlossen, sodass `DefaultStructureValidatorTestAdditional` mit seinen Adapter-Importen keine Rolle spielt.)
|
||
- **Regel D (Preview-Isolation):** Die `@see`- und `@link`-JavaDoc-Referenzen auf `DefaultStructureValidator` und `DefaultFieldValidator` in `NoOpStructureValidator` und `NoOpFieldValidator` erzeugen **keine** Bytecode-Abhängigkeiten. ArchUnit analysiert Bytecode, nicht JavaDoc — deshalb kein Verstoß.
|
||
|
||
## 6. Rest-Risiken und offene Punkte
|
||
|
||
- **Transitiv-Risiko ArchUnit:** ArchUnit analysiert nur direkten Bytecode. Transitive Abhängigkeiten über Reflection oder dynamisches Laden werden nicht erkannt. Für M1 ausreichend.
|
||
- **Regel D auf Namensbasis:** Regel D prüft über `haveSimpleNameContaining("DefaultStructureValidator")`. Falls ab M3 neue Klassen mit ähnlichem Namen entstehen, könnte die Regel unbeabsichtigt greifen. Bei M3-Aktivierung überprüfen und ggf. auf Paketnamen-Ebene umstellen.
|
||
- **Log-Rauschen in Tests:** Die ERROR/WARN-Zeilen aus `CliRunnerOperationalErrorTest` sind fachlich korrekt (sie testen Bedienfehler-Verhalten), erscheinen aber im Maven-Konsolenoutput. Das ist ein bekanntes Muster bei Tests, die Log4j2-konfigurierte Logger verwenden. Eine vollständige Unterdrückung würde auch echte Fehler verschlucken und ist bewusst nicht angestrebt.
|
||
- **SLF4J-Versionsdiskrepanz:** Das Projekt verwendet SLF4J 2.0.7, ArchUnit 1.3.0 zieht SLF4J 2.0.12 als transitive Dependency. Maven wählt 2.0.7 (nächste deklarierte gewinnt). Kein funktionales Problem, aber mittelfristig wäre eine Version-Angleichung empfehlenswert.
|
||
|
||
## 7. Empfehlungen für Folge-Arbeitspakete
|
||
|
||
- **AP11 (M1-Abnahme):** Die vier Architekturregeln können als Abnahmekriterium im Bericht gelistet werden — Nachweis: `ArchitectureTest` grün in CI.
|
||
- **Ab M3:** Regel D anpassen oder durch eine Paket-basierte Regel ersetzen, wenn `DefaultStructureValidator` und `DefaultFieldValidator` aktiv verdrahtet werden. Dabei sicherstellen, dass kein Adapter direkt auf die Implementierung, sondern nur auf die Interfaces (`StructureValidator`, `FieldValidator`) zugreift.
|
||
- **SLF4J-Version:** Bei nächster Dependency-Pflege auf SLF4J 2.0.12 anheben.
|
||
|
||
## 8. Reviewer-Checkliste
|
||
|
||
- [x] Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt
|
||
- [x] Keine Scope-OUT-Punkte wurden angefasst
|
||
- [x] Abnahmekriterien sind mit konkreten Nachweisen belegt (Tests, Dateipfade)
|
||
- [x] `mvn clean verify` ist grün (BUILD SUCCESS, 222 Tests, 0 Failures)
|
||
- [ ] Der Commit für dieses AP hat eine sprechende Message (`M1-AP10: ...`)
|
||
- [x] Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
|
||
- [x] Rest-Risiken sind ehrlich dokumentiert
|