Pulse-E2E (Playwright)

Umgebung

• Einmalig: python -m pip install --require-hashes -r requirements-dev.lock (gepinnt, wie CI) und python -m playwright install chromium.
• Server: tools/preview_server.py – echte FastAPI-App, Fake-Guild (tests/fakes.py), Fake-Login (--role admin|team), temporäre Daten, bindet nur 127.0.0.1, kein Discord, kein OAuth.
• Referenztest: tests/test_e2e_dashboard.py – Basisklasse _PreviewE2EBase (Server als Subprozess auf freiem Port mit --e2e-hooks, TMP auf TemporaryDirectory, Serverausgabe in eine Logdatei statt PIPE, externe Requests per context.route blockiert, PULSE_GITHUB_REPO=""). Neue Klasse = eigener Server; ROLE = "team" für Rechte-Tests. Gespeicherte Werte über self._config() direkt prüfen.
• Serverfehler: POST /__preview/maintenance {"on": true} (echter Restore-Sperrmodus → 503) und GET /__preview/fail (echte 500-Seite). Immer per addCleanup zurücksetzen. Client-Fehler (API 500, Netzwerk weg) per page.route(...).fulfill/abort.

Ausführen

PULSE_E2E=1 python -m unittest tests.test_e2e_dashboard -v

Ohne PULSE_E2E=1 wird bei fehlendem Playwright übersprungen (normale CI/unittest discovery). Der CI-Job e2e in .github/workflows/python-syntax.yml setzt PULSE_E2E=1.

Neuen Workflow-Test schreiben

1. Aktive Route klären: pulse_pro.py überschreibt viele Seiten (z. B. /settings → Formular an /settings/pro-goal). Im gerenderten HTML prüfen, welches form action wirklich ausgeliefert wird – nicht im ersten Treffer in webserver.py.
2. Locator über form[action="…"] + name-Attribute oder Rolle/Beschriftung, keine CSS-Klassen (Tailwind ändert sich).
3. Ablauf: goto → Status 200 → ausfüllen → with page.expect_navigation(): click() → Erfolgsmeldung im #toast[role=status] (Fehler: role=alert). Die URL verliert ?msg=… per history.replaceState, also nicht auf die URL prüfen.
4. Persistenz: Seite neu laden und gespeicherten Wert prüfen.
5. Negativfall: Browser-Validierung (min/max/required) per evaluate entfernen und prüfen, dass der Server selbst ablehnt/begrenzt und nichts Ungültiges gespeichert wird. Für Rechte: --role team auf Admin-Seite → 403, keine Änderung.
6. Mobil: viewport 375×812, is_mobile=True und scrollWidth - innerWidth <= 1 (kein horizontaler Überlauf).
7. page.on("pageerror") sammeln und am Ende [] erwarten.
8. Tests unabhängig von der Reihenfolge halten (alle Tests einer Klasse teilen einen Server).

Grenzen

Keine Tests gegen den VPS, Produktions-URLs oder echte Discord-Logins. Ergebnis ehrlich berichten (bestanden/fehlgeschlagen/übersprungen + Grund).

• Nicht bei jedem kleinen Backend-Fix laufen lassen – nur bei Dashboard-/Formular-/Routenänderungen; sonst /pulse-verify targeted.
• Warten über expect/wait_for_*, nie feste sleeps. Für lange Seiten auch Scrollposition nach Speichern prüfen.
• Der Test-Server muss im tearDownClass/finally beendet werden; danach keinen laufenden Prozess auf dem Port zurücklassen.
• Das Playwright-MCP-Plugin nur zum Erkunden/Debuggen nutzen; was dauerhaft gelten soll, gehört als Test in tests/.
• Fehlschlag dokumentieren: Test-ID, Schritt, erwarteter vs. tatsächlicher Zustand, pageerror-Ausgabe; Screenshots nur ins Scratch-/Temp-Verzeichnis.