E2E-Tests schreiben in den Demo-Mandanten #10

New Issue

2026-09-04T09:23:24Z

florian.wilde commented

2026-09-04 09:23:24 +00:00

Beobachtung

Die Playwright-Suite legt ihre Testdaten in der Beispielwehr ff-musterhausen an — also in genau dem Mandanten, den npm run db:seed erzeugt und den die Bildschirmfotos zeigen.

Stand nach fünf Phasen:

94 Atemschutz-Überwachungen (der Seed legt eine an)
49 Geräte statt der 45 aus dem Seed
35 Einsätze statt 8
Termine, Wiki-Seiten, Kalenderzugänge aus jedem Lauf

Warum das stört

Es kostet bei jeder Phase Zeit. In Phase 1 fiel INV-0001 durch die angewachsene Liste von Seite 1 und ließ fünf Tests fehlschlagen. Seither wird der Bestand von Hand aufgeräumt, sobald etwas kippt.

Die Bildschirmfotos ändern sich bei jedem Lauf. Nach Phase 7 unterschieden sich alle 72 Dateien in docs/screenshots/ — nicht weil sich die Oberfläche geändert hätte, sondern weil andere Zahlen in den Listen standen. Ein Diff, in dem 72 Bilder rauschen, verbirgt das eine, das wirklich anders aussieht.

Der Seed ist nicht mehr das, was er verspricht. Er soll eine vorzeigbare Beispielwehr sein. Ein Bestand mit 94 Überwachungen und Einträgen namens „E2E-Absage-m1x8kq" ist keine.

Lösungsvorschlag

Ein eigener Mandant für die Tests:

Ein Seed-Zusatz legt eine zweite Wehr ff-teststelle an — dieselben Stammdaten, eigener Slug.
Die E2E-Tests melden sich als deren Administrator an (E2E_ADMIN_EMAIL).
Ein Skript npm run db:test-reset setzt diesen einen Mandanten zurück, ohne die Beispielwehr anzufassen.

Die Alternative — nach jedem Lauf aufräumen — ist schlechter: ein abgebrochener Lauf lässt den Bestand dann in einem Zustand zurück, den niemand erwartet.

Betrifft

tests/e2e/*.spec.ts, prisma/seed.ts, playwright.config.ts

## Beobachtung Die Playwright-Suite legt ihre Testdaten in der Beispielwehr `ff-musterhausen` an — also in genau dem Mandanten, den `npm run db:seed` erzeugt und den die Bildschirmfotos zeigen. Stand nach fünf Phasen: - 94 Atemschutz-Überwachungen (der Seed legt eine an) - 49 Geräte statt der 45 aus dem Seed - 35 Einsätze statt 8 - Termine, Wiki-Seiten, Kalenderzugänge aus jedem Lauf ## Warum das stört **Es kostet bei jeder Phase Zeit.** In Phase 1 fiel INV-0001 durch die angewachsene Liste von Seite 1 und ließ fünf Tests fehlschlagen. Seither wird der Bestand von Hand aufgeräumt, sobald etwas kippt. **Die Bildschirmfotos ändern sich bei jedem Lauf.** Nach Phase 7 unterschieden sich alle 72 Dateien in `docs/screenshots/` — nicht weil sich die Oberfläche geändert hätte, sondern weil andere Zahlen in den Listen standen. Ein Diff, in dem 72 Bilder rauschen, verbirgt das eine, das wirklich anders aussieht. **Der Seed ist nicht mehr das, was er verspricht.** Er soll eine vorzeigbare Beispielwehr sein. Ein Bestand mit 94 Überwachungen und Einträgen namens „E2E-Absage-m1x8kq" ist keine. ## Lösungsvorschlag Ein eigener Mandant für die Tests: 1. Ein Seed-Zusatz legt eine zweite Wehr `ff-teststelle` an — dieselben Stammdaten, eigener Slug. 2. Die E2E-Tests melden sich als deren Administrator an (`E2E_ADMIN_EMAIL`). 3. Ein Skript `npm run db:test-reset` setzt diesen einen Mandanten zurück, ohne die Beispielwehr anzufassen. Die Alternative — nach jedem Lauf aufräumen — ist schlechter: ein abgebrochener Lauf lässt den Bestand dann in einem Zustand zurück, den niemand erwartet. ## Betrifft `tests/e2e/*.spec.ts`, `prisma/seed.ts`, `playwright.config.ts`

florian.wilde referenced this issue from a commit

2026-09-04 11:25:12 +00:00

Aufraeumarbeiten: ESLint, DOM-Verschachtelung, eigene Testwehr

florian.wilde referenced a pull request that will close this issue

2026-09-04 11:25:53 +00:00

Aufräumarbeiten: ESLint, DOM-Verschachtelung, eigene Testwehr #13

florian.wilde added the zu-testen label 2026-09-04 11:25:59 +00:00

florian.wilde closed this issue

2026-09-04 13:43:54 +00:00

florian.wilde removed the zu-testen label 2026-09-04 13:44:00 +00:00

Sign in to join this conversation.