Skip to content
Docksoft

Web App Testing

S

webapp-testing

Test local web apps using Playwright for automated UI verification and debugging.

testingplaywrighte2eautomationui-testing

Install

npx skills add anthropics/webapp-testing
Author
Anthropic
License
Apache-2.0
Updated
February 2026
Type
Single skill
Document
3.8 KB
Platforms
Claude Code, Claude Ai
View source

SKILL.md

Web Application Testing

To test local web applications, write native Python Playwright scripts.

Helper Scripts Available:

  • scripts/with_server.py - Manages server lifecycle (supports multiple servers)

Always run scripts with --help first to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.

Decision Tree: Choosing Your Approach

User task → Is it static HTML?
    ├─ Yes → Read HTML file directly to identify selectors
    │         ├─ Success → Write Playwright script using selectors
    │         └─ Fails/Incomplete → Treat as dynamic (below)
    │
    └─ No (dynamic webapp) → Is the server already running?
        ├─ No → Run: python scripts/with_server.py --help
        │        Then use the helper + write simplified Playwright script
        │
        └─ Yes → Reconnaissance-then-action:
            1. Navigate and wait for networkidle
            2. Take screenshot or inspect DOM
            3. Identify selectors from rendered state
            4. Execute actions with discovered selectors

Example: Using with_server.py

To start a server, run --help first, then use the helper:

Single server:

python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py

Multiple servers (e.g., backend + frontend):

python scripts/with_server.py \
  --server "cd backend && python server.py" --port 3000 \
  --server "cd frontend && npm run dev" --port 5173 \
  -- python your_automation.py

To create an automation script, include only Playwright logic (servers are managed automatically):

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
    page = browser.new_page()
    page.goto('http://localhost:5173') # Server already running and ready
    page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
    # ... your automation logic
    browser.close()

Reconnaissance-Then-Action Pattern

  1. Inspect rendered DOM:

    page.screenshot(path='/tmp/inspect.png', full_page=True)
    content = page.content()
    page.locator('button').all()
    
  2. Identify selectors from inspection results

  3. Execute actions using discovered selectors

Common Pitfall

❌ Don't inspect the DOM before waiting for networkidle on dynamic apps ✅ Do wait for page.wait_for_load_state('networkidle') before inspection

Best Practices

  • Use bundled scripts as black boxes - To accomplish a task, consider whether one of the scripts available in scripts/ can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use --help to see usage, then invoke directly.
  • Use sync_playwright() for synchronous scripts
  • Always close the browser when done
  • Use descriptive selectors: text=, role=, CSS selectors, or IDs
  • Add appropriate waits: page.wait_for_selector() or page.wait_for_timeout()

Reference Files

  • examples/ - Examples showing common patterns:
    • element_discovery.py - Discovering buttons, links, and inputs on a page
    • static_html_automation.py - Using file:// URLs for local HTML
    • console_logging.py - Capturing console logs during automation

When to use it

  • Testing local web applications interactively via Playwright
  • Verifying frontend functionality programmatically
  • Debugging UI behavior with browser console / network logs
  • Capturing screenshots of pages or component states
  • Reproducing user-reported bugs in a controlled browser

When not to

  • Production E2E test authoring — use a dedicated test framework
  • Backend API testing — no browser layer needed
  • Mobile-app testing — Playwright doesn't cover native mobile

Questions

Does it run in CI?
Designed for interactive local debugging, not CI test runs. For CI, author the equivalent test in a dedicated Playwright test file and run it in your test pipeline.
Can it capture browser console errors?
Yes — captures console logs and network events alongside screenshots. Useful for reproducing client-side errors that don't surface in server logs.

Related

Code Quality & Testing

A

.NET Diagnostics

dotnet-diag

.NET performance investigations, debugging, and incident analysis: dump analysis, perf profiling, GC tracing, async hangs, and production triage workflows.

claude-codegithub-copilotcursor+1MIT

Code Quality & Testing

S

.NET Test

dotnet-test

Run, diagnose, and migrate .NET tests: test execution, filtering, platform detection, MSTest workflows, coverage analysis, anti-patterns, and migrations across xUnit/MSTest versions.

claude-codegithub-copilotcursor+1MIT

Code Quality & Testing

A

Code Review

code-review

Perform thorough code reviews with structured feedback.

claude-codecodexcursor+1MIT

Agent tooling

Want agents that know your stack?

This index is ours, and so is the tooling behind it. If your team wants agents that understand how your own systems actually work, that is a thing we build.

Contact the dock

One address, read by the people who would do the work. No intake form, no calendar link — just an email.

tphamdn@gmail.com
Other reasons to writeWe reply within two business days