boehmitools-training/android/TEST-REPORT.md

Testbericht

Stand: 24. Juli 2026

Ergebnisübersicht

Prüfung	Ergebnis	Nachweis
Vollständiger Quellen- und Fixture-Audit	bestanden	docs/SOURCE_ANALYSIS.md, build-logs/source-audit.json
Vergleich aktueller Plugins gegen v2.0-Bundle	bestanden	nur erzeugte __pycache__-Dateien unterscheiden sich; build-logs/source-diff.log
Vorhandene Backend-Plugin-Tests	11 bestanden, 8 übersprungen	build-logs/backend-plugin-tests.log
Statische Android-Akzeptanzprüfung	728 bestanden	build-logs/static-acceptance.log
Ressourcenprüfung	8 JSON- und 7 XML-Dateien parsebar	build-logs/resource-validation.log
Kotlin-Parserprüfung ohne Android-Classpath	keine Syntax-/Parserdiagnosen	build-logs/kotlinc-syntax-summary.txt
./gradlew test	nicht ausführbar in dieser Umgebung	Wrapper-Download scheitert an nicht auflösbarem services.gradle.org; build-logs/gradle-test.log
./gradlew lintDebug	nicht ausführbar in dieser Umgebung	gleicher Infrastrukturfehler; build-logs/gradle-lintDebug.log
./gradlew assembleDebug	nicht ausführbar in dieser Umgebung	gleicher Infrastrukturfehler; build-logs/gradle-assembleDebug.log
Debug-APK	nicht erzeugt	ohne Gradle-Distribution, Android SDK und aufgelöste Abhängigkeiten wäre ein APK nicht verifizierbar

Ausgeführte Backendtests

Ausgeführt im vollständigen boehmitools-Quellstand:

python3 -m pytest -q \
  plugins/trainingsplan/tests \
  plugins/trainingstracker/tests

Ergebnis:

11 passed, 8 skipped in 0.05s

Die übersprungenen Tests stammen aus den gelieferten Testsets und wurden nicht von der Android-Implementierung ausgeblendet.

Android-Tests im Projekt

Unit- und Fixture-Tests

FixtureContractTest prüft unter anderem:

• beide gelieferten Pläne mit schema_version = 3 und contract_version = 2,
• vollständige und entitätsspezifisch eindeutige stabile IDs,
• explizite result_schema-Definitionen aller Übungen und Progressionsstufen,
• Laden beider Planvarianten,
• Migration beider alten Sessiondateien ohne Itemverlust,
• Priorität manuelle Anpassung → Progressionsstufe → Übung → Fallback,
• Vererbung nicht überschriebener result_schema-Felder,
• sichere Löschung inkompatibler Messwerte bei Einheit-/Seitenwechsel,
• Normalisierung alter Freitextergebnisse zu result_data Version 2,
• FIFO-Overlay ausstehender Session-Patches nach App-Neustart,
• Überschreibmodell für genau eine Wochen- beziehungsweise Gesamtanalyse.

ApiContractTest verwendet MockWebServer und prüft:

• exakten Session-Patch-Pfad, PATCH, Basic-Auth-Header und expected_revision,
• 202 Accepted sowie 200 am selben Analyse-Endpunkt,
• unveränderte Weitergabe von 401 und 409 revision_conflict,
• dokumentierte Editor-, Publish- und Vorschlagsstatus-Pfade.

Repository- und Instrumentationstests

RepositoryIntegrationTest prüft mit Room, WorkManager und MockWebServer:

• Netzantwort und Room-Cache,
• sichtbare 409-Weitergabe ohne Umwandlung in einen scheinbaren Offline-Erfolg,
• Erhalt des HTTP-Status 202 für die dauerhafte Analyse-Sperre.

CompactEditorUiTest setzt eine 360-dp-breite Compose-Oberfläche auf und prüft, dass lange Übungsnamen und strukturierte Ergebnisse innerhalb der verfügbaren Breite bleiben.

Diese Android-Tests sind vollständig im Projekt vorhanden, konnten in diesem Container aber nicht gestartet werden, weil bereits der Gradle-Wrapper-Download vor der Projektauswertung fehlschlägt.

Statische Akzeptanzprüfung

Ausgeführt:

python3 tools/static_acceptance.py

Ergebnis:

PASS: 728 Prüfungen

Die Prüfung deckt Buildparameter, Release-Netzwerksicherheit, Standardserver, verbotene WebView/OpenAI-Verbindungen, Basic Auth, zentrale API-Routen sowie alle gelieferten Plan- und Session-Fixtures ab.

Kotlin-Parserprüfung

Alle Kotlin-Dateien wurden zusätzlich mit dem vorhandenen standalone kotlinc eingelesen. Da Android SDK und Maven-/Gradle-Abhängigkeiten fehlen, entstehen erwartungsgemäß nicht auflösbare Android-, Compose-, Hilt-, Retrofit- und Serialization-Symbole. Die separat gefilterte Prüfung meldet jedoch keine Parserfehler wie ungeschlossene Blöcke, illegale Escapes oder unerwartete Tokens.

Dies ersetzt keinen echten Gradle-Compile-Lauf. Das vollständige Rohprotokoll ist deshalb nur Diagnosematerial und kein Bestehensnachweis.

Blocker der geforderten Gradle-Läufe

Alle drei vorgeschriebenen Befehle wurden separat ausgeführt und protokolliert. Die Laufumgebung enthält:

• keine installierte Gradle-Distribution,
• kein Android SDK, kein sdkmanager, kein adb,
• keinen vorgefüllten Gradle- oder Maven-Cache,
• keine DNS-Auflösung für services.gradle.org aus Shell-Prozessen.

Der mitgelieferte Wrapper versucht korrekt Gradle 8.11.1 zu laden und beendet sich mit UnknownHostException. Der Fehler tritt vor der Auswertung von settings.gradle.kts und damit vor Kompilierung, Tests, Lint oder APK-Erzeugung auf. Details stehen in build-logs/build-environment.log und den drei Gradle-Protokollen.

Lokal nachzuholende Abnahme

In einer normalen Android-Entwicklungsumgebung mit JDK 17, Android SDK 35 und Internetzugang:

./gradlew test
./gradlew lintDebug
./gradlew assembleDebug

Anschließend ist zusätzlich empfehlenswert:

./gradlew connectedDebugAndroidTest
adb install -r app/build/outputs/apk/debug/app-debug.apk

Die erwartete APK-Ausgabe ist app/build/outputs/apk/debug/app-debug.apk. Bis diese Befehle erfolgreich gelaufen sind, darf das Projekt nicht als vollständig buildverifiziert bezeichnet werden.