webapp-testing checks local web applications with Python Playwright. It encourages inspecting the rendered interface before choosing selectors and acting. A helper can manage one or more development servers. Search, filtering, forms, and navigation are useful starting points; merely opening the homepage is not a complete behavioral test.
Install and invoke
Send these two commands in the Claude Code chat input, one at a time. They are plugin commands, not shell commands for your operating system. The second installs the official collection containing webapp-testing.
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skills
In your project conversation, ask Claude to “use webapp-testing” and supply the task or files. The prompt below is an editable starting example. Installing the collection supplies instructions and resources; it does not supply your source material or guarantee that every runtime dependency is installed locally. If the skill is missing, check that its plugin is installed, enabled, and loaded in the current session. Do that before troubleshooting the requested output.
Give the test an expected outcome
Use webapp-testing to check search in the local product catalog.
The startup command is npm run dev on port 5173.
A known product name should show that product; an unknown term should show an empty state.
Clearing the query should restore the list.
Inspect the page before choosing locators. Save failure screenshots and browser errors without changing application code.
Provide the startup command, port, permitted account or data, and expected behavior. If the server is already running, provide its URL instead of starting a second instance on the same port. For form submissions, clarify whether the test environment creates real records.
Static HTML can be inspected directly. Dynamic applications need to reach an actionable state before DOM inspection. The bundled example uses networkidle, but an application with ongoing requests may never become completely idle. In that case, wait for the relevant element and state rather than continually extending fixed delays.
Let the helper manage server lifetime
The bundled scripts/with_server.py can launch the service, run the automation, and clean up afterward. Inspect its --help before composing the startup and port arguments. The guide also covers separate frontend and backend servers. Keep browser actions in the test script and service management in the helper. Resolve its relative path from the installed skill directory.
Choose locators from observed accessible names, roles, or stable identifiers. A search test should assert the actual matching item, empty state, and restored list, not merely the text typed into a box. These outcomes make the test capable of distinguishing success from failure.
When a check fails, inspect the assertion, screenshot, browser errors, and server readiness together. A broken control, missing dependency, unready service, and incorrect fixture require different fixes. Decide whether the application or the test needs correction only after separating those possibilities. Close the browser afterward and keep the script, test inputs, and result notes so the workflow can be repeated. If code repair is the next step, define that scope separately; this example first produces reproducible evidence.
Expand a click into a repeatable journey
For product search, prepare one real product and one nonexistent term. Search, inspect results, open a detail page, return, clear the filter, and state what should appear at every step. This checks both search and whether navigation preserves the intended state. “The page works” is too vague to identify a broken interaction.
On failure, save the URL, screenshot, console errors, and relevant request status. Decide whether the problem is in the app, server startup, or changed test data. Build selectors from labels and roles in the rendered page, not from a class name assumed to be visible because it exists in source. Close the browser and services started by the test so the next run begins from comparable conditions.
Make the environment part of the test
Before writing a test, record the base URL, seed data, browser size, and whether real form submissions are allowed. A checkout test without a sandbox-payment assumption should not be run through a production purchase. Use an authorized test account for login, without hard-coding personal sessions or private cookies. Put server startup, readiness checks, assertions, and process cleanup into one rerunnable flow so someone else can reproduce a failure without guessing what was running on your machine.
Test a user journey, not merely page opening
Start with login: provide a test account, entry URL, expected destination, and expected back or logout behavior, then ask for a Playwright assertion. A published example describes a login test that surfaced history-dependent navigation and stale auth state. Using this skill just to extract prices from a remote page is outside its local-app testing purpose. Phrase the task as starting a local service, performing actions, and asserting the result so the failure is reproducible.