Playwright steuert Browser und testet Webanwendungen. Im JavaScript- und TypeScript-Ökosystem ergänzt Playwright Test einen Runner, Fixtures, Assertions, Projekte und Berichte. QA profitiert von praktischen Befehlen, isolierten Zuständen und detaillierten Fehlerverläufen.
Das Werkzeug eignet sich für Benutzerabläufe, UI-Zustandsprüfungen und einige API-Aufgaben. Automatisches Warten ersetzt kein Anwendungsverständnis: Eine bedienbare Schaltfläche bedeutet keinen abgeschlossenen Geschäftsprozess, eine erfolgreiche HTTP-Antwort keine korrekten Daten.
Installation und Reproduzierbarkeit
Verwenden Sie für ein neues Übungsprojekt npm init playwright@latest. Wählen Sie JavaScript oder TypeScript sowie die Browserinstallation. Nutzen Sie eine von der gewählten Version unterstützte Node-Version. Behalten Sie in einem bestehenden Repository package-lock.json bei und installieren Sie Abhängigkeiten mit npm ci.
Browser-Builds sind an die installierte Playwright-Version gebunden. Aktualisieren Sie nach einem Paketupgrade die Browser und prüfen Sie die CI-Systemabhängigkeiten. Eine beliebige globale ausführbare Datei kann Unterschiede zwischen lokalen Rechnern und Agenten verursachen; dokumentieren Sie diese Wahl ausdrücklich.
Locators und zugängliche Namen
Playwright unterstützt Locators nach Rolle, Beschriftung, Text und Test-ID. Ein Locator beschreibt, wie ein Element im aktuellen Seitenzustand gefunden wird. Das ist besser als eine alte DOM-Knotenreferenz zu speichern, die die Anwendung beim Rendern ersetzen kann.
Wählen Sie Attribute nach ihrer Bedeutung. getByLabel verbindet einen Formulartest mit der zugänglichen Beschriftung; getByRole mit einem Namen beschreibt bei einer Schaltfläche die Benutzeraktion. Bei mehreren Treffern grenzen Sie den Container ein. Automatisch den ersten Treffer zu wählen kann Mehrdeutigkeit verdecken und die falsche Schaltfläche anklicken.
Ein eigenständiges Beispiel
Speichern Sie im erzeugten Projekt tests/profile.spec.js. Das Beispiel verwendet eine Seite im Arbeitsspeicher ohne Server. Starten Sie npx playwright test tests/profile.spec.js. Die Übungsregel lehnt leere Namen ab und zeigt bei nicht leeren Namen Erfolg; eine echte Speicherung findet nicht statt.
const { test, expect } = require('@playwright/test');
test('validates the name after submission', async ({ page }) => {
await page.setContent(`
<label>Name <input id="name"></label>
<button id="save">Save</button><p role="status"></p>
<script>
document.querySelector('#save').onclick = () => {
const name = document.querySelector('#name').value.trim();
setTimeout(() => {
document.querySelector('[role=status]').textContent =
name ? 'Saved' : 'Enter a name';
}, 100);
};
</script>`);
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Enter a name');
await page.getByLabel('Name').fill('Anna');
await page.getByRole('button', { name: 'Save' }).click();
await expect(page.getByRole('status')).toHaveText('Saved');
});Erwarten Sie zunächst einen Fehler für den leeren Wert und danach Erfolg für einen gültigen Wert. toHaveText wiederholt die Beobachtung bis zur erfüllten Bedingung oder zum Timeout. Asynchrone Aktionen und Assertions benötigen await; ohne await drohen falsche Reihenfolgen und unvollständige Prüfungen.
Worauf das Werkzeug tatsächlich wartet
Vor einer Aktion prüft Playwright je nach Operation notwendige Bedingungen wie Sichtbarkeit und Bedienbarkeit. Es weiß nicht, ob Hintergrundberechnungen, E-Mail-Versand oder Warteschlangenverarbeitung abgeschlossen sind. Diese Ergebnisse benötigen eine eigene beobachtbare Bedingung.
Bevorzugen Sie für dynamische UIs Web-First-Assertions. Text sofort auszulesen und mit einem einfachen assert zu vergleichen prüft nur einen Zeitpunkt. Ersetzen Sie jedoch nicht jedes Warten durch riesige Timeouts: Soll ein Ereignis nicht eintreten, behebt längeres Warten das Szenario nicht.
Übergang zu einem echten Profil
Erstellen Sie einen separaten Testbenutzer, öffnen Sie dessen Kontobereich und senden Sie einen Namen nur aus Leerzeichen. Erwarten Sie einen Fehler und den unveränderten gespeicherten Wert. Senden Sie in einem anderen Szenario einen neuen gültigen Namen und lesen Sie das Profil je nach Testziel über UI oder API zurück.
Ein Test mit Netzwerk-Mocking bestätigt die Clientbehandlung der vorgegebenen Antwort. Behalten Sie eine separate Integrationsprüfung ohne Ersetzung dieser Operation, um echte Speicherung zu überprüfen. Machen Sie die Grenze zwischen kontrolliertem UI-Fehler und echter Backendverbindung im Namen der Testsuite deutlich.
Fixtures und Unabhängigkeit
Playwright Test erzeugt mit Contexts isolierte Browserzustände. Das hilft bei Cookies und Storage, isoliert jedoch nicht automatisch Serverdatensätze. Zwei Contexts mit demselben Konto können weiterhin dasselbe Profil oder denselben Warenkorb ändern.
Fixtures können Benutzer, API-Clients und benötigte Entitäten vorbereiten. Wählen Sie ihren Gültigkeitsbereich bewusst. Eine auf Worker-Ebene geteilte Ressource muss für jeden Test dieses Workers sicher sein; veränderliche Szenariodaten sollten getrennt entstehen.
Projekte und Browsermatrix
Projekte beschreiben Konfigurationen wie Browser, Viewport, Sprachregion und weitere Parameter. Verwenden Sie eine risikobasierte Matrix statt automatisch jede Kombination zu testen. Bestätigen Sie zuerst den kritischen Ablauf und ergänzen Sie dann umgebungssensitive Bereiche.
Mobile Emulation ersetzt kein echtes Telefon mit Tastatur, Berechtigungen und Systemintegrationen. Automatisiertes WebKit ist ebenfalls kein vollständiger Test des Safari der Benutzer. Dokumentieren Sie Abdeckungsgrenzen zusammen mit den Ergebnissen.
Traces und Untersuchung
Trace Viewer zeigt Aktionen und Seitenzustände rund um einen Fehler. Speichern Sie Traces nach vereinbarter Richtlinie, etwa bei Wiederholung oder Fehler, und machen Sie sie aus CI erreichbar. Prüfen Sie vor Veröffentlichung, welche Daten in Netzwerkaufzeichnungen und Screenshots erscheinen.
Beginnen Sie bei der ersten unerfüllten Erwartung: Welche Anfrage wurde gesendet, was kam zurück und was zeigte das UI? Schreiben Sie nicht blind einen Locator um, wenn das Backend fehlt. Ein grüner Wiederholungslauf ist eine nützliche Beobachtung; der ursprüngliche Fehler muss dennoch eingeordnet werden.
Erstellen Sie bei Mehrbenutzerszenarien zwei getrennte Contexts und benennen Sie die Rolle jedes Beteiligten im Bericht. Eine Storage-State-Datei zur Loginbeschleunigung darf keine Konten vermischen oder Sitzungsdaten öffentlich machen. Prüfen Sie Umgebung und fortbestehende Gültigkeit. Scheitert die Authentifizierungsvorbereitung, benennen Sie diesen Schritt: Dutzende anschließende Elementfehler im Kontobereich sind keine unabhängigen UI-Defekte.
Fehler und praktische Schlussfolgerungen
Typische Probleme sind fehlendes await, gemeinsam veränderliche Konten, erzwungene Klicks ohne Untersuchung und reine Meldungsprüfungen. Überarbeiten Sie generierte Tests: Generatoren erleichtern den Einstieg, wählen aber weder Risiken noch Daten oder Erfolgskriterien für das Team.
Eine zuverlässige Playwright-Suite verbindet Isolation, eindeutige Locators, ausdrückliche Geschäftsergebnisse und hilfreiche Artefakte. Der schnelle Einstieg ist wertvoll, wenn das Team Serverzustand und Abdeckungsgrenzen ebenso sorgfältig behandelt.
Weiterführende Informationen
- →Playwright: Installation
- →Playwright: Automatisches Warten
- →Playwright: Test-Fixtures
- →Playwright: Trace Viewer
Eine reproduzierbare lokale Übung
Das Übungsprojekt fixiert @playwright/test 1.59.1 mit Lockfile und verwendet eine lokale Python-Fixture. Sieben Chromium-Fälle prüfen das Nickname-Formular mit leeren, kurzen, Grenz-, überlangen, Leerzeichen- und Unicode-Eingaben. Jeder Fall erhält eine eigene Seite und ein ausdrücklich erwartetes Ergebnis. Externe Konten oder Produktionsseiten sind nicht beteiligt.
npm ci
npx playwright install chromium
npm test
# If a test fails and produces a trace:
npx playwright show-trace test-results/<case-directory>/trace.zipDie Konfiguration startet den lokalen Server und bewahrt Traces bei Fehlern auf. Locators verwenden Feldbeschriftung und Schaltflächenrolle, damit der Test die Benutzerabsicht ausdrückt. Assertions werden bis zur erfüllten Bedingung oder zum Timeout wiederholt; willkürliche sleep-Aufrufe sind für dieses synchrone Formular unnötig.
await page.goto("/demo.html");
await page.getByLabel("Nickname").fill("ab");
await page.getByRole("button", { name: "Validate" }).click();
await expect(page.getByRole("alert")).toHaveText("Use 3–12 ASCII letters.");
await expect(page.getByLabel("Nickname")).toBeFocused();Ändern Sie für eine absichtliche Fehlerübung den erwarteten Fehlertext in einem lokalen Test, führen Sie nur diesen Test aus, untersuchen Sie den gespeicherten Trace und stellen Sie die Assertion wieder her. Ein bestandener Test belegt diese Prüfungen an der Fixture, nicht Barrierefreiheit oder vollständige Prüfung eines echten Produkts. Ergänzen Sie bei der Anpassung den echten Ablauf und Backend-Assertions.