11.7 Screenshots and Visual Debugging

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

Opening Hook

"A picture is worth a thousand words. When testing or debugging a web app, sometimes you need to see exactly what the page looks like at a specific moment. Playwright can take screenshots—of the full page, specific elements, or at different screen sizes. You see what the user sees, and you catch visual bugs that code inspection would miss."

Key Talking Points

1. Why Screenshots Matter in Testing

Functional tests tell you if code works. Visual tests tell you if it looks right.
Catch unintended visual changes (regression testing)
Document UI state for bug reports and discussions
Validate responsive design at different screen sizes
Prove to stakeholders that features work

What to say: "A test might pass—the button is there, it's clickable. But is it positioned correctly? Is it the right color? Is the layout broken on mobile? Screenshots answer these questions."

What to show on screen: Show side-by-side comparisons: expected UI vs. actual UI. Highlight visual differences: misaligned button, wrong color, broken layout on mobile.

2. Types of Screenshots

Full Page: Entire webpage, captures everything in the viewport
Element Screenshot: Single component or element, zoomed in
Viewport-Specific: At specific screen sizes (mobile, tablet, desktop)
Comparison/Diff: Before and after, side-by-side visual regression
Timeline Screenshots: Screenshots at key points in a workflow

What to say: "You can screenshot the whole page, one button, or the page at 5 different sizes. Pick what you need to validate."

What to show on screen: Show examples of each type. Full page screenshot of a complex site, zoomed element screenshot, responsive screenshots at 375px and 1920px.

3. Visual Regression Testing

Take baseline screenshots of your current version
Run tests, take new screenshots
Compare: did anything visual change?
If changes are intentional, update baselines
If changes are unintended, you caught a regression
Prevents accidental UI breakage

What to say: "Visual regression testing is the safety net. You update one CSS rule. The screenshot test fails. Did you intend that change? Yes? Update the baseline. No? You found a bug before it shipped."

What to show on screen: Show a baseline image and a new screenshot side-by-side. Highlight the visual difference. Explain the workflow: baseline → change → test → compare → pass/fail.

4. Using Screenshots for Debugging and Communication

Attach to bug reports: "Here's exactly what's broken"
Share with designers: "Does this match the design?"
Document features: "Here's how the feature looks and works"
Troubleshoot issues: "On my machine it looks like [screenshot], what do you see?"
Proof of work: "Testing is done, here are the results"

What to say: "Screenshots are the universal language. Words can be ambiguous. A screenshot is proof. It's evidence. It's truth."

What to show on screen: Show a bug report with a screenshot attached. Show a feature documentation page with before/after screenshots.

Demo Plan

Demo 1: Full Page Screenshot
Navigate to a real website
Ask Claude: "Take a full page screenshot of example.com and save it"
Show the screenshot being taken
Display the result
Demo 2: Element Screenshot
Navigate to a page with distinct components
Ask Claude: "Take a screenshot of just the header/nav area of example.com"
Show the focused element being captured
Display the cropped screenshot
Demo 3: Responsive Screenshots
Ask Claude: "Take screenshots of example.com at mobile (375px), tablet (768px), and desktop (1920px) widths. Show me the layouts side-by-side."
Show the page at each breakpoint
Display all three screenshots for comparison

Code Examples & Commands

Example 1: Simple Full Page Screenshot

User: "Go to example.com and take a full page screenshot. Save it as 'homepage.png'."

Claude with Playwright:
1. Navigate to example.com
2. Take full page screenshot
3. Save with filename
4. Return the image

Example 2: Element-Specific Screenshot

User: "Navigate to example.com/products and take a screenshot of just the product card in the top-left. I want to verify the design."

Claude:
1. Navigate to products page
2. Find the first product card element
3. Take screenshot of that element only
4. Return the zoomed image

Example 3: Responsive Design Testing

User: "Test the responsive design of example.com at these widths: 320px (mobile), 768px (tablet), 1024px (desktop). Take a screenshot at each and tell me if the layout changes appropriately."

Claude with Playwright:
1. Set viewport to 320px
2. Navigate
3. Take screenshot
4. Verify layout (sidebar hidden, stacked, etc.)
5. Set viewport to 768px
6. Repeat
7. Set viewport to 1024px
8. Repeat
9. Return all three screenshots and visual analysis

Example 4: Visual Regression Baseline

User: "Create a visual baseline for example.com/profile. Take a full page screenshot and save it as 'baseline-profile.png'. I'll use this to detect visual regressions."

Claude:
1. Navigate to /profile
2. Take full page screenshot
3. Save with clear naming
4. Return the image and metadata (size, timestamp, etc.)

Example 5: Before/After Comparison

User: "Take a screenshot of the button on example.com/test before clicking it, then click it and take a screenshot after. Show me both."

Claude:
1. Navigate to page
2. Take screenshot (before)
3. Click the button
4. Wait for any changes
5. Take screenshot (after)
6. Return both images side-by-side or stacked
7. Highlight the differences

Gotchas & Tips

Timing: Wait for dynamic content to load before taking screenshots. "Take a screenshot after the loading spinner disappears."
Browser Extensions: Screenshots might include extension UI in visible mode. Disable extensions for clean screenshots.
Font Rendering: Fonts can render slightly differently on different systems. Screenshots are system-specific.
Animations: If a page is animating, screenshot timing matters. "Wait for the animation to complete, then screenshot."
Scrollbar Appearance: Different OSes/browsers show scrollbars differently. Not a bug, just a platform difference.
Dark/Light Mode: Test both if your app supports switching themes. Take separate baselines.

Pro tip: Use descriptive filenames: button-hover-state.png, mobile-layout-375px.png, error-message.png. Makes it easy to understand what each screenshot represents.

Lead-out

"Screenshots are your proof. With visual testing, you never ship broken layouts or unintended changes. Next and final video: the dark side of web automation—security threats and how to protect yourself."

Reference URLs

https://playwright.dev/docs/screenshots
https://playwright.dev/docs/test-snapshots

Prep Reading

Test Playwright screenshot capabilities before recording
Prepare 2-3 real websites with interesting visual elements
Understand responsive breakpoints for mobile/tablet/desktop
Know how to compare screenshots and spot visual differences
Have examples of visual regressions (intentional vs. unintended changes)
Test screenshot quality at different viewport sizes

Notes for Daniel: This video should feel visual and interactive. Show actual screenshots, side-by-side comparisons, responsive layouts at different sizes. The benefit is obvious: "You can see every pixel." Keep the energy upbeat—visual validation is more satisfying than reading test logs. If screenshot generation is slow, show prerecorded versions. Emphasize the confidence this brings to deployments.

Quick Reference