Skills

Playwright Best Practices: aufgabenbezogene Hinweise für TypeScript-Tests

Für alle, die TypeScript-Playwright-Tests schreiben, debuggen oder pflegen; nach der offiziellen npx-Installation die Aufgabe beschreiben und Rat lesen, bevor Code geändert wird.

Official source · Playwright Best Practices Skill

Install

npx skills add https://github.com/currents-dev/playwright-best-practices-skill

Für wen

Dieser Leitfaden richtet sich an alle, die Playwright-Tests in TypeScript schreiben, debuggen oder pflegen und wollen, dass ein Agent Hinweise zur aktuellen Tätigkeit gibt. Offiziell ist er tätigkeitsgetrieben: Was du tust, zeigt auf die passenden Referenzen, statt alle Unterlagen auf einmal zu laden.

Repository:

https://github.com/currents-dev/playwright-best-practices-skill

Er passt, wenn im Repository schon Playwright-Tests liegen und du einen instabilen Fall reparieren oder Barrierefreiheitsprüfungen ergänzen willst. Das Material sagt, du musst den Skill-Namen oder “Playwright best practices” nicht aussprechen; die Aufgabe klar zu sagen reicht.

Er passt nicht zu Umgebungen, die vor allem in anderen Sprachen testen oder keinen kompatiblen Skill-Installationsweg haben. Das vorhandene Material begrenzt die Anleitung auf TypeScript-Playwright-Tests; das nicht auf ungeschriebene Sprachen ausweiten.

Erster Versuch in 3 Minuten

Nur den einen offiziell empfohlenen Weg.

Voraussetzungen: Dieser Rechner kann npx ausführen, der aktuelle Agent akzeptiert diese Installation, und im Workspace liegt ein diskutierbarer Playwright-Test. Vor der Installation bestätigen, dass du in die tatsächlich genutzte Agentenumgebung schreibst.

Installationsort: npx skills add erledigt das selbst. Das Material nennt keinen Zielordner; keinen nicht genannten Pfad ergänzen.

Kopieren und ausführen:

npx skills add https://github.com/currents-dev/playwright-best-practices-skill 

Erfolgssignal: Der Befehl endet normal. Zuerst nur lesen: einen loginbezogenen Test öffnen und dem Agenten sagen „sieh dir diesen instabilen Login-Test an, nenne zuerst mögliche Ursachen, keine Dateien ändern.“ Das offizielle Beispiel ist genau “fix this flaky login test”. Zitiert die Antwort konkrete Warte-, Ziel- oder Assertion-Probleme statt einer vagen Neufassung, wurden die passenden Referenzen genutzt.

Nach akzeptierter Analyse ausdrücklich freigeben, welche Datei geändert werden darf. Tests zu ändern hat Nebenwirkungen; vor bestätigtem Umfang nicht patchen lassen.

Anwendungsfälle

Fall 1: Instabilen Login-Test untersuchen. Entspricht der offiziellen Beispielaufgabe “fix this flaky login test”. Passt, wenn ein Test mal durchläuft und mal nicht, und du zuerst fokussierte Hinweise willst. Symptom und Fehlerprotokoll beschreiben, nur Analyse verlangen. Bei Erfolg landet die Antwort bei Referenzen zur aktuellen Tätigkeit, nicht bei allen 57 Dokumenten auf einmal. Die acht Kategorienamen stehen nicht im Material; keine Kategorien oder Dokumentdateinamen erfinden. Vor der echten Änderung Datei und erwartetes Verhalten bestätigen.

Fall 2: Barrierefreiheitstests ergänzen. Entspricht dem offiziellen Beispiel “add accessibility tests”. Passt, wenn schon ein Seitenablauf da ist und Prüfungen fehlen. Zuerst den Agenten aus dem aktuellen Seitentest vorgeschlagene Assertions nennen lassen, noch ohne Dateien. Nach Bestätigung von Selektoren und Abdeckung Fälle hinzufügen lassen. Erfolgssignal: der Rat trifft die benannte Seite, kein generisches Muster. Das vorhandene Material zeigt nur, dass diese Aufgabenbeschreibung auslöst; konkrete APIs oder Konfigurationsschlüssel fehlen.

Nutzungsgrenzen

Das vorhandene Material gibt einen Installationsbefehl und die Nutzung „Referenzen nach Tätigkeit zeigen“. Nicht auf einen nicht genannten Marktplatzbefehl, Klonpfad oder anderen Installer wechseln. Pflicht-Clients sind nicht genannt; keine Exklusivunterstützung für ein paar Agenten schreiben.

Die Referenzbibliothek umfasst 57 Dokumente in 8 Klassen; Klassennamen und Einzelpfade fehlen. Keine Dokumentpfade oder Skill-Unterordner erfinden.

Angeleitet wird Schreiben, Debuggen und Pflegen von Playwright-Tests in TypeScript. Schritte für andere Sprachen oder andere Test-Frameworks lassen sich aus dem vorhandenen Material nicht ergänzen. Tests zu ändern ändert das Repository; zuerst analysieren, dann Schreiben erlauben. Mehr steht im offiziellen Repository:

https://github.com/currents-dev/playwright-best-practices-skill