Lesson 02 · ~15 minutes · Your own app

Point Claude at Your Own App on `localhost`

A public demo is training wheels. The real mission is testing your app — which means one new skill: starting it yourself, then handing Claude the address.

Why this, why now → In Lesson 01 the app was already live on the public internet. Your real apps won't be — they run on your machine at an address like localhost:8000. This lesson teaches the one move that bridges the gap, using a tiny signup app that now ships in your workspace. After this, "test my app" works on anything you can run locally.

1. The one new idea: Claude can't start your app

Playwright MCP can open a URL, but it can't conjure your app into existence. Something has to be serving the app at a URL first. With a public demo, the internet did that for you. On your machine, you (or Claude, via a shell command) start a dev server — a small program that hosts your files at a localhost address. Then you point Claude there.

Lesson 01 (demo)	Lesson 02 (your app)
App already hosted at `demo.playwright.dev`	You start a server → app hosted at `localhost:8000`
Claude just navigates to it	Claude navigates to your local URL — same agentic loop from there on

2. Start the practice app (2 min)

Your workspace now contains practice-app/index.html — a small "Newsletter Signup" form with real validation rules (valid email required; age must be 18+). Serve it with Python's built-in web server (already on macOS). In a terminal, from the workspace folder:

cd practice-app
python3 -m http.server 8000

Leave that running. Open http://localhost:8000 in your own browser once to confirm you see the signup form. That terminal is now your dev server — closing it stops the app.

Tip: let Claude start it for you Claude Code can run that command too. In a separate Claude session you could say "start a static server for the practice-app folder on port 8000 in the background". For this lesson, starting it yourself keeps the moving parts visible — which matters while you're learning.

3. Have Claude test the happy path (5 min)

Back in Claude Code, with the server running:

Prompt to Claude

Using the Playwright browser tools, open http://localhost:8000. Fill the email field with "alex@example.com" and age with "30", then click Subscribe. Verify the page shows a success message containing "subscribed". Report PASS/FAIL and show a screenshot.

Same agentic loop as Lesson 01 — the only thing that changed is the URL points at your machine. That's the whole bridge.

4. Test that the rules actually hold (the real value)

Happy paths rarely break. Bugs hide in the rules — so test those. A good tester checks that bad input is rejected, not just that good input is accepted.¹

Prompt to Claude

Now verify the validation. Run these three checks and report PASS/FAIL for each:
(a) email "not-an-email" + age 30 → expect an error about a valid email;
(b) email "a@b.com" + age "15" → expect an error about being 18 or older;
(c) email "a@b.com" + age "30" → expect success.

You just specified a test case table — input → expected outcome — and delegated running it. This is exactly how real test suites are structured, and you wrote it in plain English.

5. Your turn — break it on purpose

Drive these yourself, one at a time, confirming Claude's verdict matches reality:

Submit with both fields empty → what error appears first? Was your guess right?
Age "twenty" (a word, not a number) → does it reject? (It should.)
Age "18" exactly → success or failure? Verify the boundary behaves as intended.
Now edit one validation rule in practice-app/index.html (e.g. require age 21+), re-test, and confirm Claude catches the change. This is regression testing in miniature.

✓ You've won this lesson when… You started a local server, pointed Claude at localhost, and it correctly reported PASS and FAIL across the validation rules — proving it tests your app, not just a demo. The last checklist item (change a rule → Claude catches it) is the moment this becomes genuinely useful.

Your teacher is in the room. Ask me anything — e.g. "how do I get Claude to start the server itself so I don't need a second terminal?", "my app uses npm run dev on port 3000 — does this still work?" (yes — just point Claude at that port), or "why test bad input at all?" Real apps with dev servers (npm run dev, vite, rails s) work identically: start it, give Claude the URL.

6. Where this is heading

You can now aim Claude at any local app. But notice your prompts say things like "the email field" — Claude is figuring out which element that is each time. Next lesson: selectors — how to refer to elements so checks stay stable when your UI shifts, and why data-testid is your friend. After that: turning a passing manual check into a saved Playwright test you can re-run forever.

References

Using Claude + Playwright MCP as an autonomous QA engineer — covers testing real flows and validation, not just happy paths. alexop.dev
Playwright MCP tool surface (navigate to any URL, including localhost). playwright.dev/docs/getting-started-mcp