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.
• Das Projekt starter läuft gegen die Ausgabe des jeweiligen Projekts — seine Specs dürfen dessen Konfiguration deshalb nicht festschreiben. Erwartungen kommen aus project.config.ts; was ein Projekt abschalten kann, wird übersprungen statt behauptet. Der Starter hatte das zunächst anders und färbte damit in jedem abgeleiteten Kundenprojekt die Kette rot — bei pnpm verify, also genau dem Befehl, der überall identisch laufen soll. Die Demo-Texte des Starters stehen in starter-demo.spec.ts und werden von pnpm starter:init entfernt; der Styleguide hat mit styleguide.spec.ts eine eigene Datei und bleibt.
• Dasselbe gilt für die Seitenliste der a11y-Prüfung: Sie kommt seit M9 aus der gebauten Ausgabe (tests/e2e/support/ausgabe.ts) und nicht aus einer Aufzählung in der Spec.
• Das Projekt forms-live und sein PHP-Server hängen daran, ob es server/forms/submit.php überhaupt gibt — ein Projekt ohne Standalone-PHP-Backend entfernt den Handler beim Initialisieren (ADR 0016).
• Visuelle Unterschiede zwischen Browser-Engines bleiben Sache der manuellen Abnahme.