prowler-test-ui_skill

Overview

This skill documents Prowler-specific Playwright E2E testing patterns and conventions for tests under ui/tests. It focuses on the Prowler base page, page objects, mandatory MCP workflow, tagging standards, and a compact test documentation template. Use it to create consistent, stable, and discoverable UI tests for Prowler features.

How this skill works

It prescribes a project layout with a Prowler base page, helpers, one spec per feature, and per-page page objects. It enforces the MCP workflow: inspect the live DOM with Playwright tools, capture snapshots, interact to confirm flows, document selectors, then write tests. It also provides Prowler-specific helper methods (notifications, navigation) and example page classes for Providers and Scans.

When to use it

• When writing new Playwright E2E tests under ui/tests for Prowler UI features
• When updating tests after UI changes to verify selectors and flows
• When creating page objects that depend on Prowler-specific behaviors (notifications, networkidle waits)
• When tagging test cases to match Prowler conventions for priority, type, feature, and test ID
• When authoring short test documentation per feature using the provided template

Best practices

• Always run the MCP workflow with Playwright tools before coding tests to avoid brittle selectors
• Keep one spec file per feature and a single page object file per page for clarity
• Use the Prowler BasePage methods for navigation and notification handling to standardize waits
• Tag tests with priority, type, feature, and a stable test ID to enable filtering and reporting
• Limit documentation to the provided template: concise preconditions, flow steps, and key verifications

Example use cases

• Add an E2E test for provider CRUD operations using ProvidersPage.addProvider and table assertions
• Create a scan-launching test using ScansPage.startScan and verify notification messages via BasePage.verifyNotificationMessage
• Investigate a flaky selector by taking MCP snapshots, updating selector in the page object, and re-running tests
• Batch-run only provider-related tests with tags like @providers and @PROV-E2E-001 for quick validation
• Document a new feature test case with the template to keep expectations and verification points clear