← 11.511.7 →
1259 words Slides

11.6 Testing Web Applications

Course: Claude Code - Power User Section: Accessing the Web Video Length: 2-5 minutes Presenter: Daniel Treasure

Opening Hook

"You built a feature. Does it actually work? Does the button do what it's supposed to? Does the form submit correctly? Does the page load in all browsers? Instead of clicking around manually, you can ask Claude to test it—automate the clicks, verify the behavior, catch regressions before they hit production."

Key Talking Points

1. What Web Application Testing Means

  • Automated testing of real browser behavior—not just unit tests
  • Testing user workflows: login, form submission, navigation, interactions
  • Visual validation: does the UI look right?
  • Functional validation: does the code work as expected?
  • Regression testing: did an update break existing functionality?
  • End-to-end (E2E) testing: full user journeys from start to finish

What to say: "Unit tests verify your code. E2E tests verify your users' experience. Playwright + Claude = automated E2E testing. You describe the scenario, Claude runs it, reports back."

What to show on screen: Show the testing workflow: Feature → Write test scenario → Claude automates it in Playwright → Result: passed/failed with screenshot evidence.

2. Testing Workflows with Playwright

  • Navigate to your app
  • Perform user actions: click, type, submit
  • Wait for expected content or state changes
  • Assert that the correct page/data appears
  • Take screenshots for visual validation
  • Report successes and failures

What to say: "A test is just a script: go here, do this, check that this appears. Playwright does the doing. Claude writes and interprets the results."

What to show on screen: Example test flow: User lands on login page → Types username and password → Clicks login → Page redirects to dashboard → Dashboard displays user name.

3. Common Testing Scenarios

  • Login/Authentication: Test login flows, password resets, session handling
  • Form Validation: Test form submission, validation errors, success states
  • Navigation: Test menu clicks, routing, back button, page transitions
  • Dynamic Content: Test loading states, pagination, filtering, search
  • Error Handling: Test error pages, error messages, recovery flows
  • Responsiveness: Test different screen sizes (with Playwright's viewport controls)

What to say: "What would you manually test? That's what Claude can automate. Every time you deploy, Claude tests your critical flows. If something breaks, you know immediately."

What to show on screen: Show examples of each scenario: a login test, a form test, a navigation test. Keep them simple but realistic.

4. Assertions and Validation

  • Text appears on page: "Expect to see 'Welcome, John'"
  • Element is visible or hidden: "Button should be enabled"
  • Page has specific structure: "Table should have 3 columns"
  • URL changes: "Should redirect to /dashboard"
  • Data is present: "User email should appear on profile page"
  • Visual consistency: "Screenshot should match baseline"

What to say: "You tell Claude what should happen. Claude tests it. If the expectation isn't met, the test fails. That's how you catch bugs."

What to show on screen: Show assertion syntax and output: "Test passed: Found 'Welcome, John' on page" or "Test failed: Expected button to be enabled but it was disabled."

Demo Plan

  1. Demo 1: Simple Form Test
  2. Navigate to a test form (or use a public form-heavy site)
  3. Ask Claude to: "Fill in the form with test data and submit. Verify success message appears."
  4. Show the form being filled

  5. Show the success validation

  6. Demo 2: Login Flow Test

  7. Navigate to a login page (use a test account or demo site)
  8. Ask Claude to: "Log in with credentials. Verify you're redirected to the dashboard."
  9. Show login automation

  10. Show verification that dashboard is displayed

  11. Demo 3: Regression Test

  12. Ask Claude to: "Run these three critical tests: login, form submission, navigation. Take screenshots for each step and report results."
  13. Show all three tests running in sequence
  14. Display the results summary

Code Examples & Commands

Example 1: Login Test

User: "Test the login flow on example.com. Use email 'test@example.com' and password 'testpass123'. Verify that after login, the user profile name 'Test User' appears on the dashboard."

Claude with Playwright:
1. Navigate to login page
2. Type email in email field
3. Type password in password field
4. Click Login button
5. Wait for redirect to dashboard
6. Find and verify text "Test User" appears
7. Take screenshot and report: "Login test PASSED - User profile verified"

Example 2: Form Submission Test

User: "Test the contact form on example.com/contact. Fill in: name='John Doe', email='john@example.com', message='Test message'. Submit and verify the success message 'Thank you for contacting us'."

Claude:
1. Navigate to contact form
2. Fill each field
3. Submit form
4. Wait for success message
5. Verify text presence
6. Report: "Form test PASSED"

Example 3: Multi-Step Workflow Test

User: "Test this workflow on example.com: 1) Login with test@example.com, 2) Navigate to products page, 3) Search for 'laptop', 4) Click first result. Take a screenshot at each step and tell me if each step succeeded."

Claude:
1. Login (screenshot)
2. Navigate to /products (screenshot, verify)
3. Search for 'laptop' (screenshot, verify results appear)
4. Click first result (screenshot, verify product details appear)
5. Report overall success

Example 4: Responsive Testing

User: "Test the homepage on example.com on mobile (375x667) and desktop (1920x1080). Verify the layout changes appropriately. Take screenshots."

Claude with Playwright:
1. Set viewport to mobile size
2. Navigate to homepage
3. Take screenshot
4. Verify responsive layout (sidebar hidden, menu visible, etc.)
5. Set viewport to desktop size
6. Navigate again
7. Take screenshot
8. Verify desktop layout (sidebar visible, expanded menu, etc.)
9. Report: "Responsive test PASSED"

Gotchas & Tips

  • Timing Issues: Sometimes elements load after delays. Playwright handles this, but sometimes you need explicit waits. Claude understands: "Wait for the loading spinner to disappear."
  • Test Data: Use test accounts and data. Don't test with real user data.
  • Environmental Differences: Dev, staging, and production might behave differently. Specify which environment you're testing.
  • Browser Differences: Chromium, Firefox, and Safari can behave differently. Playwright supports all three.
  • Screenshot Baselines: Screenshots are great for visual regression. Keep baseline images to compare against.
  • Test Isolation: Each test should be independent. Clean up data between tests if needed.

Pro tip: Run tests in headless mode for speed, but use visible mode for debugging failures. If a test fails, re-run it with visible mode to see exactly what went wrong.

Lead-out

"Testing automates quality. Next, we'll look at screenshots specifically—not just for testing, but for visual debugging, bug reports, and documentation."

Reference URLs

  • https://playwright.dev/docs/intro
  • https://playwright.dev/docs/test-assertions
  • https://playwright.dev/docs/pom

Prep Reading

  • Set up Playwright and test basic automation before recording
  • Create or find a simple test site with forms, login, navigation
  • Write 2-3 test scenarios manually first to understand the flow
  • Understand assertion syntax and how to verify page state
  • Know how to handle timing and waiting in tests
  • Prepare examples of both passing and failing test scenarios

Notes for Daniel: The energy here should be "testing is finally automated." Show the contrast: "Normally you'd click through your app manually every time you deploy. Now Claude does it automatically." The demos should be clear and sequential—each step visible, each assertion verified. If a test takes >15 seconds, show prerecorded results. Emphasize the time savings and confidence this brings.