Playwright E2E: locators, waiting, page objects, auth, network. Trigger: writing or fixing browser tests.
68
86%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Playwright's defining feature is auto-waiting: every action retries until the element is actionable. Most E2E pain comes from fighting that instead of using it — a suite full of waitForTimeout is slower, flakier, and no more correct than one that lets Playwright wait.
Two failure modes matter more than everything else below.
Flaky — the test fails while the feature works. The cause is almost always a timing guess or shared state. Wait for the condition you actually depend on (await expect(locator).toBeVisible()), never for a duration, and give each test its own data: a hardcoded test@test.com collides the moment the suite runs in parallel.
False green — the test passes while the feature is broken. Locators that match by position (div > form > input:nth-child(3)) or by styling class survive changes they should have caught, and assertions loose enough to always hold (toBeTruthy on an object that always exists) can never fail.
Prefer, in order: role with accessible name → label → data-testid → text. Reach for CSS or XPath only when nothing else identifies the element, and treat that as a signal the app is missing a test hook. Role-based locators double as an accessibility check — if you cannot find the button by its role and name, neither can a screen reader.
Keep selectors and interactions in page objects rather than in the tests, so a UI change is one edit instead of twenty. Keep tests independent and parallel-safe: no ordering assumptions, no state carried between them, unique data per run.
playwright.config.ts, pipelines, reportersYoizenSA/dev-ai-workflow
36f5af5
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.