Der Spickzettel zum Handwerk aus dem Seminar Playwright mit KI-Agenten: was ein Test braucht, damit er etwas aussagt und in der Pipeline hält. Den agentischen Teil — Planner, Generator, Healer, MCP und CLI — behandelt ein eigenes Blatt: Playwright mit KI-Agenten.
Maßgeblich ist die Originaldokumentation auf playwright.dev; dieses Blatt trifft eine Auswahl und bringt sie die Methode nicht bei — dafür ist das Seminar da.
Testmodell: die vier Ebenen
| Ebene | Bedeutung |
|---|---|
| Browser | Ein Prozess, wird pro Worker wiederverwendet |
| Browser Context | Isolierte Sitzung, billig, pro Test neu |
| Page | Ein Tab innerhalb des Kontexts |
| Worker | Prozess des Test Runners, führt Dateien parallel aus |
Isolation entsteht durch den Kontext, nicht durch Aufräumcode am Testende. Weil ein Kontext fast nichts kostet, bekommt ihn jeder Test neu — Geschwindigkeit und Isolation stehen hier nicht gegeneinander.
Modul: Ein belastbares Playwright-Fundament
Locators — welcher wann
| Locator | Passend für |
|---|---|
getByRole | Bedienelemente mit Rolle und Namen — erste Wahl |
getByLabel | Formularfelder über ihre Beschriftung |
getByText | Statische Texte und Meldungen |
getByTestId | Stellen ohne stabile Semantik, bewusst gesetzt |
| CSS oder XPath | Letzter Ausweg, an Struktur statt Bedeutung gebunden |
Die Reihenfolge ist eine Rangfolge: Je näher ein Locator an der Wahrnehmung eines Menschen liegt, desto länger hält er. Rollenbasierte Locators finden das Element nur, wenn es auch für Assistenztechnik erreichbar ist.
Modul: Ein belastbares Playwright-Fundament
Web-first Assertions
// Warten von selbst bis zum Zeitlimit — kein waitForTimeout nötig
await expect(alarm).toHaveText('Nicht lieferbar');
await expect(kasse).toBeEnabled();
await expect(page.getByTestId('zeile')).toHaveCount(2);
await expect(alarm).not.toBeVisible(); // Fehlerfall absichernSichtbarkeit ist fast keine Aussage, der Wert ist die Aussage. Die negative Assertion fehlt in erzeugtem Code am häufigsten.
Modul: Ein belastbares Playwright-Fundament
Artefakte und ihre Aussage
| Artefakt | Beantwortet |
|---|---|
| Screenshot | Wie sah die Seite im Moment des Fehlers aus |
| Video | Welche Schritte gingen dem Fehler voraus |
| Trace | Was genau tat der Test, und was tat die Seite |
| HTML-Report | Welche Tests liefen, wie lange, mit welchem Ergebnis |
Der Trace legt Aktion, DOM-Zustand, Netzwerk und Konsole auf eine gemeinsame Zeitachse und beantwortet damit das Was und das Warum zugleich. Videos ergänzen ihn, ersetzen ihn nicht.
Modul: Ein belastbares Playwright-Fundament
Kommandozeile
npx playwright test --ui # interaktiv, mit Zeitachse
npx playwright test warenkorb --debug # schrittweise, Browser hält an
npx playwright codegen <url> # aufzeichnen, Locators vorschlagen
npx playwright show-trace trace.zip # Nachschau
npx playwright test --repeat-each=3 --workers=4 # Instabilität provozieren
npx playwright test --shard=1/4 # verteilen
npx playwright merge-reports --reporter html blobs/Module: Playwright-Fundament · Parallelität, Testdaten und große Suites
Fixtures und Page Objects
| Form | Zweck |
|---|---|
| Hilfsfunktion | Ein technischer Handgriff, ohne eigenen Zustand |
| Komponentenobjekt | Ein wiederkehrender Bereich, etwa die Kopfzeile |
| Page Object | Eine Seite mit ihren Locators und Handlungen |
| Fixture | Ausgangszustand samt Aufräumen, injiziert in den Test |
| Fixture-Art | Konsequenz |
|---|---|
| Standard, Geltungsbereich Test | Pro Test neu aufgebaut und abgeräumt |
scope: 'worker' | Einmal je Worker, von allen Tests geteilt |
auto: true | Läuft, auch ohne dass ein Test sie anfordert |
option: true | Wert kommt aus der Konfiguration, nicht aus dem Test |
export const test = base.extend<Fixtures>({
warenkorb: async ({ page }, use) => {
const seite = new WarenkorbSeite(page);
await seite.oeffnen();
await use(seite); // danach: aufräumen — greift auch bei Fehlschlag
},
});Assertions bleiben im Test. Wandern sie ins Page Object, liest man hinterher eine Klickfolge, die irgendwo im Hintergrund etwas behauptet. Geteilter Zustand in einer Worker-Fixture ist erlaubt — nur darf kein Test ihn verändern.
Modul: Wartbarkeit mit Fixtures und Domänenabstraktionen
Parallelität und Kollisionen
| Begriff | Bedeutung |
|---|---|
| Parallelisierung | Mehrere Worker auf einer Maschine |
| Sharding | Aufteilung der Suite auf mehrere Maschinen |
fullyParallel | Verteilt einzelne Tests, nicht nur Dateien |
| Serieller Bereich | Tests hängen voneinander ab, Folgetests entfallen |
| Kollisionsquelle | Symptom |
|---|---|
| Gemeinsames Benutzerkonto | Abmeldung oder Zustand aus dem Nachbartest |
| Fester Datensatz | Erwarteter Bestand stimmt sporadisch nicht |
| Globaler Backend-Zustand | Ergebnisse hängen an der Reihenfolge |
| Dateisystem oder Downloads | Zugriffskonflikte, überschriebene Dateien |
| Ports und externe Dienste | Zeitweise Verbindungsfehler ohne Muster |
Ein Test, der allein grün und in der Suite rot ist, ist fast immer ein
Kollisionsfall — und die Ursache sitzt im Test, der gleichzeitig lief. Die
Diagnose in dreißig Sekunden: --workers=1. Verschwindet der Fehler, ist es
eine Kollision.
Gegenmittel ist nicht weniger Parallelität, sondern eine eindeutige Kennung je
Test — etwa aus testInfo.workerIndex und testInfo.testId — plus Aufräumen in
der Fixture statt am Testende.
Modul: Parallelität, Testdaten und große Suites
API-gestütztes Testen
| Aufgabe | Weg |
|---|---|
| Ausgangszustand herstellen | API, schnell und stabil |
| Bedienbarkeit prüfen | Oberfläche, sonst fehlt die Aussage |
| Nachbedingung prüfen | API, wenn die Oberfläche sie nicht zeigt |
| Fremde Dienste ausschalten | Netzwerkaufrufe abfangen und beantworten |
Die Regel: über die Oberfläche nur prüfen, was auch ein Mensch dort prüfen
würde. Der Anmeldezustand ist zwischen APIRequestContext und BrowserContext
austauschbar — einmal per API anmelden, im Browser weiterarbeiten.
Modul: Testabdeckung strategisch ausbauen
CI-Läufe
| Auslöser | Umfang |
|---|---|
| Push auf einen Zweig | Smoke-Auswahl, wenige Minuten |
| Pull Request | Vollständige Regression, ein Browser |
| Nächtlich | Browsermatrix und lange Szenarien |
| Vor einem Release | Alles, inklusive Quarantäne-Prüfung |
| Nur-in-CI-Fehler | Gegenmittel |
|---|---|
| Weniger Ressourcen, andere Zeiten | Web-first Assertions, keine festen Pausen |
| Andere Zeitzone oder Sprache | locale und timezoneId in der Konfiguration |
| Fehlende Systempakete | playwright install --with-deps |
| Andere Testdaten | Daten je Lauf erzeugen statt vorauszusetzen |
Für stabile Läufe empfiehlt die Dokumentation zunächst einen Worker; Breite entsteht über Sharding, nicht über Worker. Browser-Caching lohnt selten — das Wiederherstellen dauert etwa so lange wie das Herunterladen.
Modul: Playwright-Tests in der CI-Pipeline
Typische Fallen
- Selektoren aus generierten Klassennamen übernehmen, die der nächste Build ändert.
- Feste Wartezeiten statt Web-first Assertions — sie verdecken Ladeprobleme und brechen auf langsamer CI.
- Nur Sichtbarkeit prüfen, statt was in einem Element steht.
- Negative Assertions weglassen und damit Fehlerfälle nie absichern.
- Traces nur lokal aktivieren und in der Pipeline genau dann keine haben.
- Fehlschläge durch Wiederholung wegdrücken, statt sie zu lesen.
- Ein einziges Testkonto für die ganze Suite — die häufigste Kollisionsursache.
- Aufräumen ans Testende legen, wo es bei einem Fehlschlag nie erreicht wird.
- Shards ohne Zusammenführung fahren und vier Teilberichte hinterlassen.
- Assertions in Hilfsfunktionen verstecken und dem Test seine Aussage nehmen.