webapp-testing
Skill2 starsChanged 4 months agoMITView on GitHub
Automated end-to-end web application testing using Playwright. Use when the user wants to write automated tests for a web app, test frontend functionality, verify UI behaviour programmatically, debug interactions in a browser, capture screenshots of a running app, check for console errors, or test a user flow from login to completion.
- Reads credentials
- Installs packages
196 other projects use a version of this.
Adopted by
Most recently taken up by
- rvdbreemen/OTGW-firmwaretheir own version, first seen Nov 8, 2026
- BrightGold70/skillstheir own version, first seen Nov 8, 2026
- DnsQueen/orcinus-skillstheir own version, first seen Nov 8, 2026
- Liang-MH/skillstheir own version, first seen Nov 8, 2026
- smart-coder-labs/nexus-mindtheir own version, first seen Nov 8, 2026
- codewhale-hq/codewhale-plugin-marketplacetheir own version, first seen Nov 8, 2026
Used with
Projects with it also use academy-guide, skill-share and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnthropicSkillacademy-guide
Stop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: "how do I", "how can I", "getting started with", "what can Claude do", "teach me", "learn to use"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.
Also in 8 projects that use this
ArogyaReddySkillskill-share
A skill that creates new Claude skills and automatically shares them on Slack using Rube for seamless team collaboration and skill discovery.
Also in 23 projects that use this
SKB3002Skillintelligent-routing
Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
Also in 5 projects that use this
ArogyaReddySkillraffle-winner-picker
Picks random winners from lists, spreadsheets, or Google Sheets for giveaways, raffles, and contests. Ensures fair, unbiased selection with transparency.
Also in 26 projects that use this
zephyrwang6Skilltopic-collector
AI热点采集工具。从Twitter/X、Product Hunt、Reddit、Hacker News、博客等采集AI相关热点内容。当用户说"开始今日选题"、"采集热点"、"看看今天有什么新闻"、"今日AI热点"时触发。聚焦领域:Vibe Coding、Claude Skill、AI知识管理、AI模型更新、AI新产品、海外热点。
Also in 4 projects that use this
zephyrwang6Skilldeepl
Übersetzt Texte, Dokumente und XLIFF-Dateien via DeepL API. Verwende für Übersetzungen mit /deepl translate, /deepl file oder /deepl xliff.
Also in 4 projects that use this
- +4 more from zephyrwang6
- +1 more from ArogyaReddy
Other versions196 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 196
- anthropics/skills★ 189ksame name
- ComposioHQ/awesome-claude-skills★ 75ksame name
- github/awesome-copilot★ 41ksame name
- ComposioHQ/awesome-codex-skills★ 17ksame name
- composio-community/awesome-codex-skills★ 16ksame name
- vudovn/ag-kit★ 8.2ksame name
- vudovn/antigravity-kit★ 8.2ksame name
- Galaxy-Dawn/claude-scholar★ 5.9ksame name
- microsoft/FluidFramework★ 4.9ksame name
- Prat011/awesome-llm-skills★ 1.7ksame name
186 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- agent-memorySkill
- ai-engineerSkill
- api-designSkill
- autoplanSkill
- backend-devSkill
- benchmarkSkill
- brand-guidelinesSkill
- code-reviewerSkill
- commit-messageSkill
- database-architectSkill
- data-engineerSkill
- debuggerSkill
- design-explorerSkill
- devex-engineerSkill
- devops-platformSkill
- doc-coauthoringSkill
- forward-deployment-engineerSkill
- frontend-designSkill
- internal-commsSkill
- java-developmentSkill
- land-and-deploySkill
- mcp-builderSkill
- office-hoursSkill
- pdfSkill
- performance-optimizerSkill
- plan-ceo-reviewSkill
- plan-design-reviewSkill
- plan-eng-reviewSkill
- pptxSkill
- product-engineerSkill
- prompt-engineerSkill
- python-developmentSkill
- qa-engineerSkill
- react-developmentSkill
- release-engineerSkill
- research-agentSkill
- retro-engineerSkill
- safety-guardrailsSkill
- security-engineerSkill
- skill-creatorSkill
- spec-authorSkill
- sre-canarySkill
- system-designSkill
- technical-writerSkill
- test-writerSkill
- theme-factorySkill
- typescript-developmentSkill
- xlsxSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 190 edited versions we read keep these.
5
Distinctive
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 14
Reconnaissance before action: Never assume a selector exists.
- Distinctive: line 16
Test what the user experiences: Test by role, text, and label — not by CSS class or XPath.
- Distinctive: line 19
Screenshot on failure: Every test should capture a screenshot when it fails — this is the single fastest debugging tool available.
- Distinctive: line 78
Before writing any selectors, discover the actual rendered DOM:
- Distinctive: line 103
Run this first. Read the output.
“Common” is measured: kept by at least 6 in 10 of the 190 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Web App Testing (Playwright)
Manual testing finds bugs once. Automated tests find them every time. This skill writes Playwright scripts that test real browser behaviour — clicks, forms, navigation, network calls, and visual state — reliably and repeatably.
Web App Testing Principles
- Reconnaissance before action. Never assume a selector exists. Navigate, wait for load, inspect the DOM, then act. Selectors that work in dev break in staging. Discover them at runtime.
- Wait for real readiness.
networkidleis not always enough. Wait for the specific element you need, not just page load. - Test what the user experiences. Test by role, text, and label — not by CSS class or XPath. Classes change; user-facing text is more stable.
- One test, one user journey. A test that does login + checkout + confirmation + email verification is four tests jammed together. Split them.
- Tests must clean up after themselves. A test that leaves state (created users, placed orders) that affects the next test is a flaky test waiting to happen.
- Screenshot on failure. Every test should capture a screenshot when it fails — this is the single fastest debugging tool available.
Step 0: Choose the Right Approach
Is the app running?
├── NO → Start it first with with_server.py helper (if available)
│ or: npm run dev / python app.py in background
└── YES
└── Is it static HTML (no JS framework)?
├── YES → Read HTML directly, write selectors from source
└── NO (React, Vue, Svelte, etc.)
→ Reconnaissance first: navigate → networkidle → screenshot → inspect → actProject Setup
Install Playwright
npm init -y
npm install -D @playwright/test
npx playwright install chromium # or: install firefox, webkit too
# Python
pip install playwright
playwright install chromiumConfig (playwright.config.ts)
import { defineConfig } from "@playwright/test";
export default defineConfig({
testDir: "./tests",
timeout: 30_000,
retries: process.env.CI ? 2 : 0, // retry in CI, not locally
use: {
baseURL: process.env.BASE_URL ?? "http://localhost:3000",
headless: true,
screenshot: "only-on-failure", // always capture on failure
video: "retain-on-failure",
trace: "retain-on-failure",
},
webServer: {
command: "npm run dev",
port: 3000,
reuseExistingServer: !process.env.CI,
},
});Reconnaissance Pattern (Always Do This First)
Before writing any selectors, discover the actual rendered DOM:
import { test, expect } from "@playwright/test";
test("reconnaissance — inspect login page", async ({ page }) => {
await page.goto("/login");
await page.waitForLoadState("networkidle");
// Take screenshot to see what's there
await page.screenshot({ path: "screenshots/login.png", fullPage: true });
// List all interactive elements
const buttons = await page.locator("button").all();
for (const btn of buttons) {
console.log("Button:", await btn.textContent(), await btn.getAttribute("type"));
}
const inputs = await page.locator("input").all();
for (const input of inputs) {
console.log("Input:", await input.getAttribute("name"), await input.getAttribute("type"));
}
});Run this first. Read the output. Then write your real tests based on what actually exists.
Writing Tests
Preferred Selector Order (most stable → least stable)
// 1. Role + name (most resilient — matches what users see)
page.getByRole("button", { name: "Sign in" })
page.getByRole("textbox", { name: "Email address" })
page.getByRole("link", { name: "Forgot password?" })
// 2. Label (for form fields)
page.getByLabel("Email address")
page.getByLabel("Password")
// 3. Test ID (when team adds them explicitly)
page.getByTestId("submit-button")
// 4. Text (for non-interactive elements)
page.getByText("Welcome back")
// 5. CSS selector (last resort — fragile, breaks on refactor)
page.locator(".login-form button[type='submit']")
// ❌ Never use XPath — brittle, unreadable
page.locator("//button[@class='btn-primary']")Complete Login Test
import { test, expect } from "@playwright/test";
test.describe("Authentication", () => {
test("user can log in with valid credentials", async ({ page }) => {
await page.goto("/login");
await page.waitForLoadState("networkidle");
// Fill form
await page.getByLabel("Email").fill("test@example.com");
await page.getByLabel("Password").fill("password123");
// Submit
await page.getByRole("button", { name: "Sign in" }).click();
// Verify redirect to dashboard
await page.waitForURL("**/dashboard");
await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
});
test("shows error on invalid credentials", async ({ page }) => {
await page.goto("/login");
await page.getByLabel("Email").fill("wrong@example.com");
await page.getByLabel("Password").fill("wrongpassword");
await page.getByRole("button", { name: "Sign in" }).click();
await expect(page.getByText("Invalid email or password")).toBeVisible();
// Should NOT redirect
await expect(page).toHaveURL(/.*login.*/);
});
});Form Submission Test
test("user can submit contact form", async ({ page }) => {
await page.goto("/contact");
await page.waitForLoadState("networkidle");
await page.getByLabel("Name").fill("Jane Doe");
await page.getByLabel("Email").fill("jane@example.com");
await page.getByLabel("Message").fill("This is a test message with sufficient length.");
// Intercept the API call to verify it's made
const responsePromise = page.waitForResponse(
response => response.url().includes("/api/contact") && response.status() === 200
);
await page.getByRole("button", { name: "Send message" }).click();
await responsePromise;
await expect(page.getByText("Message sent successfully")).toBeVisible();
});Navigation Test
test("main navigation links work", async ({ page }) => {
await page.goto("/");
await page.waitForLoadState("networkidle");
const navItems = [
{ link: "Products", url: /.*products.*/ },
{ link: "Pricing", url: /.*pricing.*/ },
{ link: "About", url: /.*about.*/ },
];
for (const { link, url } of navItems) {
await page.getByRole("navigation").getByRole("link", { name: link }).click();
await expect(page).toHaveURL(url);
await page.goBack();
await page.waitForLoadState("networkidle");
}
});API Interception
test("handles API failure gracefully", async ({ page }) => {
// Mock the API to return an error
await page.route("**/api/users", route => {
route.fulfill({ status: 500, body: JSON.stringify({ error: "Server error" }) });
});
await page.goto("/users");
await page.waitForLoadState("networkidle");
// App should show error state, not crash
await expect(page.getByText("Something went wrong")).toBeVisible();
await expect(page.getByRole("button", { name: "Try again" })).toBeVisible();
});Visual Testing
Screenshot comparison
test("dashboard looks correct", async ({ page }) => {
await page.goto("/dashboard");
await page.waitForLoadState("networkidle");
// Wait for data to load before snapping
await page.waitForSelector("[data-testid='chart']");
await expect(page).toHaveScreenshot("dashboard.png", {
maxDiffPixelRatio: 0.02 // allow 2% pixel difference
});
});Console error detection
test("page has no console errors", async ({ page }) => {
const errors: string[] = [];
page.on("console", msg => {
if (msg.type() === "error") errors.push(msg.text());
});
page.on("pageerror", err => errors.push(err.message));
await page.goto("/");
await page.waitForLoadState("networkidle");
expect(errors).toHaveLength(0);
});Python Playwright
import pytest
from playwright.sync_api import Page, expect
def test_login(page: Page):
page.goto("/login")
page.wait_for_load_state("networkidle")
page.get_by_label("Email").fill("test@example.com")
page.get_by_label("Password").fill("password123")
page.get_by_role("button", name="Sign in").click()
page.wait_for_url("**/dashboard")
expect(page.get_by_role("heading", name="Dashboard")).to_be_visible()
def test_shows_error_on_invalid_login(page: Page):
page.goto("/login")
page.get_by_label("Email").fill("wrong@example.com")
page.get_by_label("Password").fill("wrong")
page.get_by_role("button", name="Sign in").click()
expect(page.get_by_text("Invalid email or password")).to_be_visible()# Run
pytest tests/ -v
# With headed browser (see what's happening)
pytest tests/ --headed
# Generate HTML report
pytest tests/ --html=report.htmlDebugging Failures
// Slow down execution to watch what's happening
test.use({ actionTimeout: 5000 });
// Pause and inspect in headed mode
await page.pause(); // opens Playwright Inspector
// Log every network request
page.on("request", req => console.log("→", req.method(), req.url()));
page.on("response", res => console.log("←", res.status(), res.url()));
// Dump current DOM
const html = await page.content();
console.log(html.slice(0, 2000));
// Check what Playwright sees
await page.screenshot({ path: "debug.png", fullPage: true });CI Integration
# .github/workflows/e2e.yml
name: E2E Tests
on: [push, pull_request]
jobs:
e2e:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npm ci
- run: npx playwright install --with-deps chromium
- run: npx playwright test
env:
BASE_URL: http://localhost:3000
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/Common Pitfalls
| Mistake | Why it fails | Fix |
Not waiting for networkidle on dynamic apps | JS hasn't hydrated yet — selectors not found | await page.waitForLoadState("networkidle") |
| Hardcoding CSS classes as selectors | Classes change on refactor | Use getByRole, getByLabel, getByText |
| Not closing browser on error | Orphaned browser processes | Use test.afterEach cleanup or using |
page.click() before element is visible | Race condition | await page.getByRole(...).click() waits automatically |
| Writing one giant test | Flaky, hard to debug, slow to isolate | One test per user journey |
| No screenshot on failure | Can't debug without knowing what was on screen | Set screenshot: "only-on-failure" in config |
Definition of Done — Web App Testing
- Reconnaissance run first — selectors discovered from rendered DOM
getByRole,getByLabel, orgetByTextused — no raw CSS selectors- Each test covers exactly one user journey
waitForLoadState("networkidle")called after navigation- Screenshot on failure configured in
playwright.config.ts - Both happy path and error paths tested
- API mocking tested for failure states
- Tests are independent — no shared mutable state between tests
- Tests clean up after themselves (created data removed in
afterEach) - CI pipeline runs tests on every PR
- Failure artifacts (screenshots, traces) uploaded in CI
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.

