playwright-review

Playwright Review

Overview

Specialized review for Playwright E2E tests focusing on: (1) ARIA label enforcement, (2) UI/layout issues like buttons bumping footer, (3) Playwright performance optimizations. Spawns general-purpose subagent.

When to Use

Use when:

• Reviewing Playwright E2E tests
• Adding accessibility checks to tests
• Optimizing test performance
• Checking for UI/layout test coverage

Don't use when:

• Reviewing unit tests
• Reviewing backend code

Steps

1. Get Git SHAs

Check conversation context first. If not available:

git rev-parse origin/main
git rev-parse HEAD

2. Invoke Playwright-Focused Code Reviewer

Task(general-purpose):
  description: Playwright test review for [feature]
  model: "sonnet"

  prompt:
    # Playwright Test Review Agent

    You are a Playwright testing expert reviewing E2E tests for accessibility, UI quality, and performance.

    **Your task:**
    1. Review Playwright test code
    2. Apply systematic accessibility checklist (ARIA labels)
    3. Identify UI/layout issues tests should catch
    4. Find Playwright performance optimizations
    5. Assess test quality and coverage

    ## What to Review

    [Brief summary - e.g., "E2E tests for event submission form"]

    ## Files to Review

    [List test files or use git diff]

    ```bash
    git diff --stat BASE_SHA..HEAD_SHA
    git diff BASE_SHA..HEAD_SHA
    ```

    ## Playwright-Specific Review Checklist

    **CRITICAL: Check EVERY category systematically.**

    ### Accessibility - ARIA Labels & Attributes

    **For EVERY form field, button, and interactive element:**

    - **ARIA labels present?**
      - Does test verify form fields have associated labels?
      - Example: `await expect(page.getByLabel('Email')).toBeVisible()`
      - If using getByLabel(), that's good - but does the HTML actually have the label?

    - **ARIA invalid on errors?**
      - After form validation fails, check: `await expect(input).toHaveAttribute('aria-invalid', 'true')`
      - Are error messages linked via `aria-describedby`?

    - **ARIA live regions for dynamic content?**
      - Toast notifications: should have `role="alert"` or `aria-live="polite"`
      - Loading states: `aria-busy="true"`
      - Success messages announced?

    - **Focus management?**
      - After modal opens: focus trapped inside?
      - After form submits: focus moves to success message?
      - After page navigation: focus on main heading?

    - **Landmark roles?**
      - Main content in `<main>` or `role="main"`?
      - Navigation in `<nav>` or `role="navigation"`?
      - Forms in `<form>` (semantic HTML)?

    - **Button semantics?**
      - Clickable non-buttons have `role="button"`?
      - Buttons have accessible names (text or aria-label)?
      - Icon-only buttons have `aria-label`?

    **Tests should VERIFY these exist, not just assume they do.**

    ### UI/Layout Issues

    **Visual regressions tests should catch:**

    - **Buttons bumping against footer?**
      - Test with screenshot comparison
      - Test at different viewport heights
      - Example: `await expect(page).toHaveScreenshot('page-layout.png')`

    - **Viewport overflow?**
      - Content scrollable when needed?
      - No horizontal scrollbar unless intentional?
      - Mobile viewport (375x667) tested?

    - **Interactive elements accessible?**
      - Buttons/links not cut off by overflow?
      - Form fields visible when focused?
      - Dropdowns don't extend below viewport?

    - **Spacing issues?**
      - Adequate margin between footer and content?
      - Touch targets 44x44px minimum (mobile)?
      - Form fields not overlapping?

    **Add tests like:**
    ```javascript
    test('layout has adequate spacing at mobile viewport', async ({ page }) => {
        await page.setViewportSize({ width: 375, height: 667 });
        await page.goto('/submit/event');