E2E-Strategie

E2E-Tests haben den Ruf, langsam, fragil und teuer zu sein. Das stimmt — wenn man sie falsch einsetzt.

Die richtige Frage

Nicht: „Sollen wir E2E-Tests haben?”

Sondern: „Was testen wir mit E2E, was wir mit Unit-Tests nicht testen können?”

Antwort: Integrationen, Deployment-Konfiguration, echte Browser-Behavior, Cross-Remote-Kommunikation in Module Federation.

Playwright in Taskly

• Test-Isolation durch Preview-Deployments: Jeder Feature-Branch kann eine eigene Preview-Umgebung deployen. E2E läuft gegen die echte gestackte Umgebung, nicht gegen Mocks.
• Dedizierte SCS-Tests: Jede Self-Contained-System hat eigene E2E-Tests, die gegen ihre Preview-URL laufen.
• Affected-basiert: E2E wird nur getriggert, wenn das SCS oder seine Dependencies betroffen sind.

Was wir nicht mit E2E testen

• Komponentenverhalten (Unit-Tests + Vitest)
• Store-Logik (Unit-Tests)
• API-Contracts (separate Contract-Tests)

E2E testet den kritischen Pfad: Login, Hauptnavigation, Happy-Path eines Use-Cases.

Die Kosten

Playwright-Tests sind langsam (~30-120s pro Test in echter Umgebung). Sie brauchen eine laufende Umgebung. Sie sind nicht immer deterministisch.

Die Gegenfrage: Was kostet ein Deployment, das einen kritischen Pfad bricht und erst im Prod bemerkt wird?