# 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:

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

Ergebnis:

```text
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:

```bash
python3 tools/static_acceptance.py
```

Ergebnis:

```text
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:

```bash
./gradlew test
./gradlew lintDebug
./gradlew assembleDebug
```

Anschließend ist zusätzlich empfehlenswert:

```bash
./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.