- Home
- Skills
- Dtinth
- Agent Skills
- Playwright Testing
playwright-testing_skill
2
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill dtinth/agent-skills --skill playwright-testing- SKILL.md9.1 KB
Overview
This skill helps you write and run reliable end-to-end tests for web applications using Playwright. It provides guidance on resilient locators, isolation, page object structure, and patterns to handle flaky UI overlays. Use it to convert user flows into maintainable automated tests that reflect real user behavior.
How this skill works
The skill inspects user-facing behavior and recommends using Playwright locators (getByRole, getByText, etc.) with filtering and chaining to build stable selectors. It enforces test isolation, web-first assertions, and page object patterns that wrap interactions in tester classes. It also describes locator handlers for transient overlays and gives guidance on when to change app code to make tests more reliable.
When to use it
- Automating critical user flows (login, checkout, search)
- Validating visible behavior rather than implementation details
- Building a test suite that must run independently and in CI
- When tests fail due to transient UI overlays or flaky timing issues
- When you want a maintainable page object structure for many tests
Best practices
- Target visible, accessible attributes (getByRole first) instead of CSS classes or internal names
- Make each test isolated: reset storage, cookies, and state between tests
- Prefer web-first assertions (await expect(locator).toBeVisible()) over manual checks
- Use locator chaining, filtering, and intersection/or to narrow matches and avoid brittle selectors
- Handle unpredictable overlays with addLocatorHandler rather than sleeps or timeouts
- Refactor test helpers into Tester page objects only after a pattern stabilizes
Example use cases
- Create a login test using a LoginPageTester class that exposes goto() and login()
- Test a product list by filtering listitem locators and asserting Add to cart buttons
- Handle a modal that intermittently appears using addLocatorHandler to dismiss it
- Write isolated tests that seed their own data and clear local storage before each run
- Use role and text locators to verify accessibility-driven UI changes
FAQ
Prefer accessibility-driven locators: getByRole first, then text, label, placeholder, alt, title, and finally test ids. This yields the most user-centric and resilient selectors.
What if an external service causes flakiness?
Avoid calling third-party endpoints in end-to-end tests. Mock or stub external services, or run integration tests in a controlled environment you manage.
When should I change application code to make tests pass?
Improve testability when brittle behavior arises: add semantic attributes, test IDs, or disable interactions until ready rather than adding sleeps or fragile selectors.