Florian WildeandClaude Opus 5
e500ad6c0e
Drei Nachbesserungen aus dem Gesamtlauf der E2E-Tests: Die Offline-Seite blieb stehen, wenn nur eine einzelne Anfrage unterwegs abgebrochen war. Fuer ein Wandtablet ist das falsch herum gedacht: dort tippt niemand auf "erneut versuchen". Sie versucht es jetzt selbst — sofort, wenn der Browser wieder Netz meldet, sonst alle zehn Sekunden. Dazu ein Wiederholungsversuch auch fuer den lokalen Testlauf. Vier gleichzeitige Arbeiter gegen "next dev" plus bcrypt mit zwoelf Runden lassen gelegentlich einen Test ins Zeitlimit laufen, der einzeln zuverlaessig gruen ist — verstreut ueber alle Dateien, nicht an einer Stelle. Ein echter Fehler faellt zweimal durch und bleibt sichtbar. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
73 lines
2.7 KiB
TypeScript
73 lines
2.7 KiB
TypeScript
import { defineConfig, devices } from "@playwright/test";
|
|
|
|
/**
|
|
* End-to-End-Tests.
|
|
*
|
|
* Voraussetzung: der Stack läuft (docker compose up -d) und die Datenbank ist
|
|
* migriert und geseedet. Der Entwicklungsserver wird bei Bedarf selbst
|
|
* gestartet — ein bereits laufender wird wiederverwendet.
|
|
*/
|
|
const BASIS_URL = process.env.E2E_BASIS_URL ?? "http://localhost:3100";
|
|
|
|
export default defineConfig({
|
|
testDir: "./tests/e2e",
|
|
fullyParallel: true,
|
|
forbidOnly: Boolean(process.env.CI),
|
|
/**
|
|
* Ein Wiederholungsversuch auch lokal.
|
|
*
|
|
* Der Grund ist derselbe wie bei den großzügigen Zeitlimits unten: "next
|
|
* dev" übersetzt jede Route beim ersten Aufruf, und mit vier gleichzeitigen
|
|
* Arbeitern kommt dazu die Anmeldung mit bcrypt (12 Runden, wie in
|
|
* Produktion). Unter dieser Last läuft gelegentlich ein Test ins Zeitlimit,
|
|
* der einzeln zuverlässig grün ist — verstreut über alle Dateien, nicht an
|
|
* einer Stelle. Ein echter Fehler fällt zweimal durch und bleibt sichtbar.
|
|
*/
|
|
retries: process.env.CI ? 2 : 1,
|
|
/**
|
|
* Bewusst wenige Worker: "next dev" übersetzt jede Route erst beim ersten
|
|
* Aufruf. Zu viele gleichzeitige Erstaufrufe lassen den Server so lange
|
|
* kompilieren, dass die Navigation ins Zeitlimit läuft — und das sieht dann
|
|
* nach einem Fehler in der Anwendung aus, ist aber keiner.
|
|
*/
|
|
workers: process.env.CI ? 1 : 4,
|
|
reporter: process.env.CI ? [["list"], ["html", { open: "never" }]] : [["list"]],
|
|
/** Großzügig, aus demselben Grund. Gegen einen Produktionsbuild reicht ein Bruchteil. */
|
|
timeout: 90_000,
|
|
/**
|
|
* Ab Phase 3 großzügiger: mit fünfzig Routen dauert die erste Übersetzung
|
|
* einer bisher unbesuchten Seite unter Last auch mal zwanzig Sekunden. Das
|
|
* sind Wartezeiten des Entwicklungsservers, keine der Anwendung — vorher
|
|
* schlugen dadurch gelegentlich Tests fehl, die einzeln laufen und grün sind.
|
|
*/
|
|
expect: { timeout: 25_000 },
|
|
|
|
use: {
|
|
baseURL: BASIS_URL,
|
|
trace: "on-first-retry",
|
|
screenshot: "only-on-failure",
|
|
video: "retain-on-failure",
|
|
// Die Oberfläche ist durchgängig deutsch — auch der Browser soll es sein.
|
|
locale: "de-DE",
|
|
timezoneId: "Europe/Berlin",
|
|
},
|
|
|
|
projects: [
|
|
{ name: "chromium", use: { ...devices["Desktop Chrome"] } },
|
|
// Am Terminal im Gerätehaus steht ein Touchgerät — deshalb mitgetestet.
|
|
// Bewusst mit Chromium statt WebKit: das Terminal läuft auf einem
|
|
// Android-Tablet im Kiosk-Browser, nicht auf einem iPad.
|
|
{
|
|
name: "tablet",
|
|
use: { ...devices["Galaxy Tab S4 landscape"], browserName: "chromium" },
|
|
},
|
|
],
|
|
|
|
webServer: {
|
|
command: "npm run dev",
|
|
url: BASIS_URL,
|
|
reuseExistingServer: !process.env.CI,
|
|
timeout: 180_000,
|
|
},
|
|
});
|