playwright-testing
Playwright E2E-Tests meistern
Das Schreiben zuverlässiger End-to-End-Tests ist ohne richtige Anleitung eine Herausforderung. Diese Fähigkeit bietet Expertenwissen zu Playwright, einschließlich Locators, Page Objects, Fixtures und Debugging-Techniken, um robuste Browser-Automatisierungstests zu erstellen.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "playwright-testing". Hilf mir, einen Playwright-Test für ein Kontaktformular mit Name, E-Mail- und Nachrichtenfeldern zu schreiben
Resultado esperado:
- Hier ist ein Playwright-Test für dein Kontaktformular:
- Verwendet Role-basierte Locators für Formularfelder und Submit-Button
- Folgt dem Arrange-Act-Assert-Muster für Klarheit
- Enthält ordnungsgemäße Assertions für Erfolgsmeldung
- Verwendet fill() für schnelle Eingabe anstelle von type()
- Teststruktur:
- - beforeEach: Zur Kontaktseite navigieren
- - Haupttest: Felder ausfüllen, absenden, Erfolgsmeldung verifizieren
Usando "playwright-testing". Wie organisiere ich meine Tests für eine große Anwendung mit vielen Seiten
Resultado esperado:
- Verwende das Page Object Model-Muster:
- Erstelle eine Basis-Page-Klasse mit gemeinsamer Funktionalität
- Jede Seite erhält ihre eigene Klasse mit Locators und Aktionen
- Halte Tests sauber, indem du Page-Methoden aufrufst, nicht direkt interagierst
- Vorteile:
- - Locators an einem Ort definiert
- - Einfach zu aktualisieren, wenn sich die UI ändert
- - Tests bleiben lesbar und wartbar
Usando "playwright-testing". Meine Tests sind langsam, weil sie sich jedes Mal einloggen. Wie kann ich das beschleunigen
Resultado esperado:
- Verwende Storage State zur Wiederverwendung von Authentifizierung:
- Erstelle eine auth.setup.ts, die sich einmal einloggt und den State speichert
- Konfiguriere Projekte in playwright.config.ts zur Verwendung des gespeicherten States
- Vorteile:
- - Login läuft einmal anstelle von pro Test
- - Tests starten schneller mit vorgespeicherten Cookies
- - Testet authentifizierte Flows dennoch korrekt
Auditoría de seguridad
Riesgo bajoThis is a legitimate Playwright testing skill providing E2E testing guidance. The 209 static findings are almost entirely false positives triggered by documentation patterns (code blocks in markdown) rather than executable code. The setup script validates local Playwright installation using standard dev tooling patterns. No credential theft, data exfiltration, or malicious patterns detected.
Problemas de riesgo bajo (2)
Factores de riesgo
⚡ Contiene scripts (1)
📁 Acceso al sistema de archivos (1)
⚙️ Comandos externos (1)
Puntuación de calidad
Lo que puedes crear
E2E-Test-Suiten erstellen
Umfassende End-to-End-Test-Suiten mit Playwright-Best-Practices für Selektoren, Assertions und Testorganisation erstellen.
Web-Anwendungen testen
Zuverlässige Browser-Automatisierungstests für Web-Anwendungen schreiben, einschließlich Formulartests, API-Mocking und visuelle Regressionstests.
Testabdeckung skalieren
Cross-Browser-Tests, parallele Ausführung und CI/CD-Integration für produktionsqualitative Test-Pipelines einrichten.
Prueba estos prompts
Hilf mir, meinen ersten Playwright-Test zu schreiben. Ich möchte ein Login-Formular mit E-Mail- und Passwortfeldern und einem Submit-Button testen.
Meine Playwright-Tests scheitern, weil Elemente nicht gefunden werden. Zeige mir, wie ich Role-basierte Locators anstelle von CSS-Selektoren für bessere Zuverlässigkeit verwende.
Zeige mir, wie ich meine Playwright-Tests auf das Page Object Model umstelle. Ich habe Tests für Login-, Dashboard- und Benutzerprofilseiten.
Wie mocke ich API-Antworten in Playwright, um Fehlerbehandlung, langsame Netzwerke und verschiedene Datenszenarien ohne echtes Backend zu testen?
Mejores prácticas
- Verwende Role-basierte Locators (getByRole, getByLabel) anstelle von CSS-Selektoren für zugängliche, resiliente Tests
- Bevorzuge Auto-Waiting-Assertions anstelle von expliziten Waits, um flaky Tests zu vermeiden
- Organisiere Tests mit Page Objects, um Page-Logik von Test-Assertions zu trennen
Evitar
- Verwendung von CSS-Selektoren mit nth-child oder index-basierter Positionierung - bricht, wenn sich die UI ändert
- Verwendung von waitForLoadState('networkidle') - unzuverlässig mit WebSockets und Analytics
- Tests ohne ordnungsgemäße Assertions schreiben - verifiziere immer erwartete Ergebnisse
- Anmeldedaten in Tests hardcoden - verwende stattdessen Umgebungsvariablen und Storage State