Webapp testing
Browser-tests a local webapp end to end — starts the app, installs Playwright if missing, writes a spec for the critical path plus edge cases, runs headless, captures screenshots, console and network logs on failure, and reports a pass/fail table with repro steps. Degrades to curl smoke tests when no browser is available. Use when the user says "test my app", "does signup still work", "check the site before I deploy", or "this page is blank".From its SKILL.md
npx -y skills add alebgl77/claude-inc --skill webapp-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, 789 tokens by cl100k_base, as published. Nobody here has run it
Webapp Testing — QA Engineer
"Browser-test your app"
If a human can click it, it can break. Prove the critical path in a real browser before anything ships.
When to use
- "Test my app" / "check the site before I deploy" — the pre-ship confidence run
- "Does signup still work?" after touching auth, forms, or routing
- "This page is blank" / "the button does nothing" — reproduce with evidence, not vibes
- Regression pass after a dependency bump, refactor, or CSS overhaul
- The project has zero e2e coverage and needs a first spec to seed CI
Workflow
- Start the app in the background (
npm run dev,uvicorn app:app,rails s, ...) and poll until it answers —curl -sf http://localhost:<port>in a retry loop. Never test a dead server. - Ensure Playwright:
npx playwright --version; if missing,npm i -D @playwright/test && npx playwright install chromium. - Map the critical path from the app's purpose: load → key action (signup, add-to-cart, submit) → expected end state.
- Add 2–3 edge cases: invalid input, empty state, refresh mid-flow, double-submit.
- Write
tests/e2e.spec.tsasserting on visible text and roles (getByRole,getByText) — never brittle CSS selector chains. - Run headless:
npx playwright test --reporter=line. - On any failure capture the trio — screenshot, console errors, failed network requests — into
test-results/and reference each by path. - Report the pass/fail table (format below) with exact repro steps per failure.
- No browser possible (install blocked, sandboxed env)? Degrade gracefully: build a curl smoke suite — status code per route, key strings in bodies, form POST round-trips — and label the report
mode: curl-fallback.
Output format
## QA report — <app> @ http://localhost:<port> (mode: playwright-chromium | curl-fallback)
| # | Scenario | Result | Evidence |
|---|----------|--------|----------|
| 1 | Signup happy path | PASS | — |
| 2 | Invalid email rejected | FAIL | test-results/02-invalid-email.png |
Failures:
2. Invalid email rejected
Repro: goto /signup → fill email "nope" → click Submit
Expected: inline validation error
Actual: HTTP 500; console TypeError at validate.js:14; POST /api/signup → 500
Re-run: npx playwright test --reporter=line
Quality bar
- Server confirmed answering before the first test ran
- Critical path plus at least two edge cases covered
- Selectors use roles and text, not CSS chains that break on restyle
- Every failure ships with screenshot, console, and network evidence
- Repro steps followable by a human with zero context
- Entire suite re-runs with one stated command
Example
Ask: "Check the store before I deploy."
Produced: app started on :3000, tests/e2e.spec.ts with five scenarios (browse → add to cart → checkout, plus empty-cart and out-of-stock edges). Result 4 PASS / 1 FAIL.
| 5 | Empty-cart checkout | FAIL | test-results/05-empty-cart.png |
Repro: goto /cart (empty) → click Checkout → HTTP 500
Verdict: hold the deploy until the empty-cart 500 is fixed; everything else is green.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 1 of the 12 instructions most e2e browser skills give in 789 tokens
Counted across 499 of the 513 authors here whose files we hold, read 2026-09-06
- Capture screenshots, videos, and traces on failurehere, and in 32 of 499, across 23 files
- Close the browser when donein 22 of 499
- Interact with elements using snapshot refsin 21 of 499, across 20 files
- Wait for specific network responses instead of fixed timeoutsin 20 of 499, across 10 files
- Keep tests independent with no shared statein 19 of 499, across 17 files
- Use Page Object Model classes to encapsulate page interactionsin 19 of 499, across 9 files
- Locate elements with data-testid attributesin 19 of 499, across 10 files
- Quarantine flaky tests with fixme or skipin 17 of 499, across 7 files
- Upload test artifacts after every CI runin 17 of 499, across 8 files
- Wait on conditions instead of using fixed sleepsin 17 of 499, across 13 files
- Clean up test data after each testin 17 of 499, across 16 files
- Test user-visible behavior, not implementation detailsin 16 of 499, across 10 files
Said here and by no other author read
- Start the app and poll until it answers
- Confirm the server responds before running any test
- Map the critical path from the app's purpose
- Add two or three edge cases
- Write selectors using roles and visible text
- Run the suite headless
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.