Rollback-Punkt vor Expo SDK 54 / RN 0.81 Upgrade. UI/UX: - Profile: ProfileHeader redesign (sign-in chip + member-since), StatsBar 3 pill cards, Demographics accordion completed (Geburtsjahr, Geschlecht, Familienstand, Beruf-split, Wohnort), Pro-Trial-Banner, Approved-Domains list, DigaMissionBanner - Settings: section-based layout, neutral icons (matched Header dropdown style) - Header dropdown: extended with logout + games-page link - Notifications page: skeleton dummy data - Locales: i18n keys for new screens New components: - WheelPickerModal: native iOS UIPickerView wheel for long lists (Geburtsjahr 91 items, Bundesland 16, Stadt 30+/Bundesland) - OptionsBottomSheet: iOS-style options sheet (used briefly for Geschlecht, currently unused — kept for potential future use) - germanCities.ts: Top-cities per Bundesland (DSGVO-clean static data) New libs (NewArch-codegen verified): - @react-native-menu/menu 2.0.0 (UIMenu wrapper, Apple HIG-konform) - @lodev09/react-native-true-sheet 3.10.1 (UISheetPresentationController wrapper — ABER incompatible mit RN 0.79.6, Build-Error → Trigger für SDK-54-Upgrade) Maestro E2E: - Initial setup mit auth/community/profile/urge flows Scripts: - build-ios-clean.sh: Xcode DerivedData + ios/build cleanup vor expo run:ios Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.7 KiB
Maestro E2E — Local Setup (Phase A)
Phase A: lokales CLI, 0 Cost, kein Cloud-Account. Phase B (post-TestFlight): Maestro Cloud fuer CI-Reports + Multi-Device-Parallel — Entscheidung steht aus.
1. Maestro CLI installieren
curl -Ls "https://get.maestro.mobile.dev" | bash
Danach Shell neu starten oder:
export PATH="$PATH:$HOME/.maestro/bin"
Verify:
maestro --version
# Erwarteter Output: Maestro CLI 1.x.x
2. App auf Device / Simulator bauen
Maestro benoetigt eine laufende App-Installation. Expo Dev-Client oder Production-Build.
iOS Simulator
# Im rebreak-native Verzeichnis:
cd apps/rebreak-native
# Dev-Build auf Standard-Simulator (erster verfuegbarer):
pnpm exec expo run:ios
# Spezifischer Simulator (Name aus "xcrun simctl list devices"):
pnpm exec expo run:ios --device "iPhone 15"
Alternativ (wenn dev-iphone.sh vorhanden):
bash apps/rebreak-native/dev-iphone.sh
Android Emulator
Emulator muss vorher gestartet sein (Android Studio -> Device Manager).
bash apps/rebreak-native/install-android.sh
Oder direkt:
pnpm exec expo run:android
Bundle-ID
org.rebreak.app (iOS + Android identisch) — steht so in app.config.ts und in den
Flow-Headern als appId: org.rebreak.app.
3. Env-Vars setzen
Flows benoetigen Test-User-Credentials. Nie hardcoden — immer als Env-Vars uebergeben.
export E2E_TEST_USER=claude-android-test
export E2E_TEST_PASSWORD=<Passwort aus Infisical>
Oder via Infisical:
infisical run -- maestro test apps/rebreak-native/.maestro/auth/signin.yaml
Variablen die Flows erwarten:
| Var | Beschreibung |
|---|---|
E2E_TEST_USER |
Username ohne @rebreak.internal |
E2E_TEST_PASSWORD |
Passwort des Test-Users auf Staging |
Wichtig: Der Backend-Server haengt @rebreak.internal automatisch an den Username.
In den Flows steht deshalb ${E2E_TEST_USER}@rebreak.internal als E-Mail-Input.
4. Flows ausfuehren
Einen einzelnen Flow
maestro test apps/rebreak-native/.maestro/auth/signin.yaml \
--env=E2E_TEST_USER=claude-android-test \
--env=E2E_TEST_PASSWORD=<passwort>
Alle Flows (sequenziell)
maestro test apps/rebreak-native/.maestro/
Mit ENV-Datei-Uebergabe:
maestro test \
--env=E2E_TEST_USER=claude-android-test \
--env=E2E_TEST_PASSWORD=<passwort> \
apps/rebreak-native/.maestro/
Spezifische Subdirectory
maestro test apps/rebreak-native/.maestro/auth/
5. Flow-Entwicklung: Maestro Studio
Visual Flow-Builder im Browser — zeigt Screen-Snapshot + verfuegbare Elemente.
# App muss laufen auf Device/Simulator:
maestro studio
Browser oeffnet auf http://localhost:9999. Elemente anklicken, YAML auto-generieren,
dann in .maestro/<area>/<scenario>.yaml speichern.
6. Tipps fuer stabile Flows
Warte auf Animationen:
- waitForAnimationToEnd:
timeout: 4000
Splash-Screen, Screen-Transitions und API-Calls brauchen Zeit.
Faustregel: nach launchApp min. 5000ms, nach Navigation 2000-4000ms.
Flaky Tests debuggen:
# Output-Logs waehrend Run:
maestro test --format junit --output report.xml apps/rebreak-native/.maestro/auth/signin.yaml
# Screenshot bei Fehler: Maestro macht automatisch einen Screenshot im Fehlerfall.
# Findet sich unter ~/.maestro/tests/<timestamp>/
Selektoren — Prioritaet:
id: "<testID>"— stabielste Option. RN-Prop:testID="mein-btn".text: "..."— nur fuer statische, locale-unabhaengige Strings.point: "x%, y%"— letzter Ausweg, bricht bei Screen-Size-Aenderungen.- Niemals
text:fuer i18n-Strings (t('...')-Output) wenn Locale-Wechsel moeglich.
Device angeben (Multi-Device):
maestro test --device=<DEVICE_ID> apps/rebreak-native/.maestro/
# Device-IDs: `adb devices` (Android) / `xcrun simctl list` (iOS)
7. App-State vor Test-Lauf
clearState: true in jedem Flow-Header stellt sicher dass:
- Auth-Session geleert ist
- Kein persistierter State (MMKV / AsyncStorage) den Flow stoert
- Jeder Flow von einem definierten Ausgangspunkt startet (Login-Screen)
Test-User muss vorab auf dem Staging-Backend existieren:
- Username:
claude-android-test - E-Mail:
claude-android-test@rebreak.internal - Account: email-confirmed, kein Admin-Flag
- Erstellung: nur per Service-Role-Key +
auth.admin.createUser({ email_confirm: true })(nicht im Flow selbst — Test-User ist persistent)
8. Flow-Uebersicht
| Flow | Was wird geprueft |
|---|---|
auth/signin.yaml |
App startet, Login funktioniert, Home-Feed sichtbar |
urge/start-session.yaml |
SOS-Button im Dropdown erreichbar, Lyra-Screen laedt |
community/post.yaml |
ComposeCard oeffnet, Text-Input funktioniert, Post sendet |
profile/view-profile.yaml |
Profil-Navigation via Dropdown, ProfileScreen laedt |
9. Phase B — Maestro Cloud (Zukunft, post-TestFlight)
Was bei Cloud-Wechsel geaendert werden muss:
- Maestro-Cloud-Account anlegen:
maestro cloud login - CI-Run-Befehl aendern:
maestro cloud apps/rebreak-native/.maestro/ - ENV-Vars in CI-Secret-Store hinterlegen (GitHub Actions Secrets / Infisical CI-Integration)
- Multi-Device-Matrix:
--device ios/--device androidseparat schedulen - Report-URL aus Cloud-Output in PR-Kommentare posten (GitHub Actions Step)
Bis dahin: lokaler CLI reicht fuer Pre-Release-Smoke-Tests.