marcus/asv-format-validator
1
0
Fork 0
Code Activity
Files
b5044f62a97f2756049cd4c1b80c0f3792877ef1
asv-format-validator/docs/arbeitspakete/m1/berichte/AP10-bericht.md
T
marcus b5044f62a9 Umsetzung von M1
2026-04-20 10:11:19 +02:00

6.8 KiB
Raw Blame History

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

  • Alle im Arbeitspaket genannten Scope-IN-Punkte sind nachweislich umgesetzt
  • Keine Scope-OUT-Punkte wurden angefasst
  • Abnahmekriterien sind mit konkreten Nachweisen belegt (Tests, Dateipfade)
  • mvn clean verify ist grün (BUILD SUCCESS, 222 Tests, 0 Failures)
  • Der Commit für dieses AP hat eine sprechende Message (M1-AP10: ...)
  • Keine Regeln der Grunddokumente (Spec, Fachliche, Technik) wurden verletzt
  • Rest-Risiken sind ehrlich dokumentiert
View Git Blame Copy Permalink