- Home
- Skills
- Prowler Cloud
- Prowler
- Playwright
playwright_skill
- Python
12.8k
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 prowler-cloud/prowler --skill playwright- SKILL.md9.5 KB
Overview
This skill provides Playwright end-to-end testing patterns focused on Page Object Model, selector strategy, MCP exploration workflow, and Prowler-specific UI conventions. It standardizes file layout, selector priorities, reuse rules, tagging, and documentation formats to produce reliable, maintainable tests. Use it to create concise, stable Playwright tests that integrate with Prowler UI conventions when applicable.
How this skill works
Start by exploring the page with the MCP workflow: navigate, snapshot DOM, interact, capture screenshots, verify transitions, and record real selectors before writing code. Tests follow a strict file structure where each page has a matching page object, spec, and markdown doc; reuse existing page objects and move shared logic to BasePage or helpers.ts. Selectors prioritize accessibility queries (getByRole, getByLabel), avoid fragile locators, and tag tests for priority and traceability.
When to use it
- When writing a single test to add to an existing spec (request contains “a test”, “add test”).
- When generating a full test suite for a feature (request contains “comprehensive tests”, “generate tests”).
- When implementing Page Object Model patterns to improve reuse and maintainability.
- When testing Prowler UI flows and authentication—use prowler-test-ui conventions and env setup.
- When you can run MCP tools to inspect the live UI before coding.
Best practices
- Always run the MCP exploration workflow before creating selectors or tests; never assume DOM shape.
- Prefer getByRole and getByLabel for interactive elements and form controls; use getByText only for static content; use getByTestId as last resort.
- Search tests/ for existing Page Objects and import them; create new page objects only when the page does not exist.
- Move shared navigation, notification waiters, and verification helpers into BasePage; put test data generators and API helpers into helpers.ts.
- Keep all tests for a page in a single spec file and document each test case in the page’s .md file following the provided template.
Example use cases
- Add one test to verify a form validation message in an existing sign-up.spec.ts file.
- Generate a full login suite using LoginPage and tags like @critical and @e2e to enable filtered runs.
- Explore a Prowler dashboard page with MCP tools, capture selectors, then create stable Page Object methods.
- Refactor duplicated notification wait logic into BasePage and update multiple page objects to reuse it.
- Create test documentation files for each feature following the concise test case template.
FAQ
Proceed with test creation using documentation and code analysis, but mark selectors as higher-risk and plan a follow-up MCP pass when available.
How should I choose selectors?
Use getByRole/getByLabel first, getByText sparingly for static text, and getByTestId only when all other options fail; avoid CSS classes and IDs that are brittle.