0004 — End-to-End-Tests gegen den Build, nur Chromium

Status: angenommen · Milestone: M3

Kontext

Ab M3 gehören End-to-End-Tests zur Qualitätskette. Sie tragen später die Last der sicherheitsrelevanten Zusagen: dass vor der Consent-Entscheidung kein Tracking-Skript lädt (M5), dass ein Formular die Fehlercodes des Vertrags einhält (M6). Damit diese Zusagen etwas wert sind, muss die Suite prüfen, was tatsächlich ausgeliefert wird — und darf nicht versehentlich etwas anderes prüfen.

Entscheidung

Drei Festlegungen:

Gegen den Build. Playwright startet astro preview auf dem erzeugten dist/, nicht den Dev-Server.

Kein reuseExistingServer. Die Option steht auf false, auch lokal. Der Testlauf startet immer seinen eigenen Server auf Port 4331.

Nur Chromium. Ein einziges Browser-Projekt, Desktop Chrome.

Begründung

Gegen den Build: Genau die Artefakte, um die es geht, entstehen erst beim Bauen — gebündelte und minimierte Skripte, erzeugte Bildformate, Sitemap, robots.txt. Der Dev-Server liefert andere Dateien aus. Ein grüner Lauf gegen ihn würde eine Aussage über etwas treffen, das so nie beim Kunden ankommt.

Kein reuseExistingServer: Beim Einrichten lief die Suite gegen einen Docker-Container, der zufällig auf Astros Standardport 4321 horchte. Alle Seiten lieferten 404 — die Barrierefreiheitsprüfung war trotzdem grün, weil eine leere Fehlerseite keine Verstöße hat. Genau so entsteht ein Test, der nichts prüft und trotzdem Vertrauen erzeugt. Ein belegter Port muss den Lauf abbrechen, nicht umleiten. Der abweichende Port 4331 senkt zusätzlich die Wahrscheinlichkeit einer Kollision.

Nur Chromium: Die Suite prüft Dokumentstruktur, Barrierefreiheit und Netzwerkverhalten. In diesen Bereichen verhalten sich die Engines gleich. Ein zweiter Browser verdoppelt die Laufzeit jedes Pull Requests, ohne andere Fehler zu finden.

Verworfene Alternativen

Dev-Server statt Preview. Schneller Start, aber prüft die falschen Dateien.

Chromium, Firefox und WebKit. Der Standardvorschlag von Playwright. Für eine Suite, die kein visuelles Rendering prüft, ist das dreifache Laufzeit ohne zusätzlichen Ertrag. Sollten später visuelle Regressionstests dazukommen, wird diese Entscheidung neu bewertet.

reuseExistingServer: !process.env.CI. Die Voreinstellung aus Playwrights Dokumentation. Lokal bequem, aber sie hat genau den oben beschriebenen Fehler erzeugt.

Konsequenzen

• Browser müssen einmalig installiert werden (pnpm exec playwright install chromium); die CI erledigt das mit --with-deps bei jedem Lauf.
• Wer parallel einen Dev-Server laufen lässt, stört den Testlauf nicht — die Ports sind verschieden.
• Der Styleguide ist die zentrale Prüffläche der a11y-Tests. Ein neues Primitive ist erst fertig, wenn es dort in allen Varianten vorkommt.
• Visuelle Unterschiede zwischen Browser-Engines bleiben Sache der manuellen Abnahme.