playwright-regression-testing
Skill256 starsChanged 23 days agoMITView on GitHub
Govern Playwright TypeScript regression suites across many tests. Use when asked to plan, select, tier, execute, or optimize suites with risk/change analysis, tags, CI/CD, sharding, flaky-test management, or suite-health metrics; not for authoring one UI spec. Keywords: regression strategy, smoke tests, test selection, CI pipeline, flaky tests, test sharding, impact analysis, git diff.
In this repository11 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- a11y-playwright-testingSkill
- accessibility-selenium-testingSkill
- api-testingSkill
- grill-me-qaSkill
- playwright-cliSkill
- playwright-e2e-testingSkill
- qa-investigationSkill
- qa-manual-istqbSkill
- webapp-selenium-testingSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 60
No change-based selection — running everything regardless of what changed wastes CI budget.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Playwright Regression Testing (TypeScript)
Strategy and best practices for automated regression testing of web applications using Playwright with TypeScript.
Activation: This skill is triggered when working with regression test strategy, test suite selection, test prioritization, CI/CD pipeline testing, flaky test management, test sharding, or optimizing test execution for web applications using Playwright.
When to Use This Skill
- Plan regression suites with risk-based and change-based test selection
- Organize tests into tiers (smoke, sanity, selective, full regression)
- Optimize execution with parallelization, sharding, and time-budget strategies
- Integrate with CI/CD using GitHub Actions pipelines
- Manage flaky tests with quarantine, retry policies, and root cause tracking
- Monitor suite health with execution time, flake rate, and detection metrics
- Select tests after changes using git diff analysis and impact mapping
Do NOT Use For
- Authoring a single UI spec or page-object model (use
playwright-e2e-testing). - Driving a live browser interactively for debugging (use
playwright-cli). - Selenium/Java regression suites (use
webapp-selenium-testing). - API contract testing in isolation (use
api-testing).
Prerequisites
| Requirement | Details |
| Node.js | v18+ recommended |
| Playwright | @playwright/test package |
| TypeScript | typescript configured in project |
| Browsers | Installed via npx playwright install |
| Git | Required for change-based test selection |
| GitHub Actions | Recommended CI/CD platform |
Quick Reference
Tiers: Smoke (<2min, every commit) → Sanity (<10min, every PR) → Selective (<30min, on merge) → Full (<60min, nightly/pre-release).
Key tags: @smoke, @sanity, @regression, @e2e, @api, @destructive — exactly one per test, never on describe() blocks. Domain-specific extensions (e.g., @a11y in accessibility skills) are allowed alongside, but only one execution tag per test.
CLI: npx playwright test --grep @smoke | --grep @regression | --grep-invert @destructive | --shard=1/4 | --last-failed
For full tier model, regression types table, and tag taxonomy, see references/regression-catalogs.md.
Red Flags
- Treating flaky tests as "fixed" by adding retries or
waitForTimeout— quarantine and root-cause instead. - Running the full suite on every commit — use tiered selection (smoke on commit, full nightly).
- Quarantining tests silently with no tracking ticket — quarantine must be temporary and owned.
- No change-based selection — running everything regardless of what changed wastes CI budget.
- Ignoring suite-health metrics (rising duration, climbing flake rate) until they block releases.
References
| Document | Content |
| Regression Strategy | Tier model (smoke→full), regression types, triggers, directory layout, test tagging and tag taxonomy |
| Regression Selection | Test selection (change-based, risk-based, historical, time-budget) and test naming conventions |
| Regression Best Practices | Locator priority, web-first assertions, test independence, test.step() reporting, complete worked example test |
| CI/CD Integration | GitHub Actions tiered pipeline, sharding, merge reports, Playwright config, performance optimization, CLI reference |
| Flaky Management | Retry policies, quarantine strategies, detection checklist, suite health metrics, troubleshooting |
Verification
- Smoke test subset identified — Tagged
@smoketests run in under 2 minutes - No test duplication — Each scenario tested exactly once at the appropriate level
- Test isolation verified — Running tests in random order produces same results as sequential
- Flaky test baseline established — All tests pass 5/5 consecutive runs
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.