agentleFS
MicrosoftKnown publishermicrosoft-foundry/foundry-agent-webapp/.github/skills/testing-with-playwright/SKILL.md

testing-with-playwright

Skill124 starsChanged 7 months agoMITView on GitHub

Provides Playwright MCP testing workflow for the web application. Use when testing UI changes, verifying chat functionality, debugging frontend issues, or validating state transitions in the browser.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    CRITICAL: Always test changes before completion.

    line 8
  2. Distinctive:

    Browser console logs: - Check console messages for state transitions and errors

    line 60
  3. Distinctive:

    VS Code terminal logs: - Check terminal output for backend/frontend server logs

    line 61
  4. Distinctive:

    Check browser console for state transitions and errors

    line 80
  5. Distinctive:

    Verify network requests for API calls

    line 81
  6. Distinctive:

    Check VS Code terminal output for backend compilation and request logs

    line 85
  7. Distinctive:

    After UI component or API endpoint changes

    line 91
  8. Distinctive:

    Before committing multi-step implementations

    line 92
  9. Distinctive:

    When user reports issues

    line 93
  10. Distinctive:

    Use console logs for state verification.

    line 139

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Testing with Playwright MCP

CRITICAL: Always test changes before completion.

Subagent Delegation for Testing

Screenshot operations blow up context fast (~2000-5000 tokens each). Delegate to subagent for:

  • Multi-step UI test scenarios
  • Visual regression verification
  • Accessibility audits
  • Screenshot-heavy debugging

Delegation Pattern

runSubagent(
  prompt: "TESTING task with Playwright MCP.
    
    **Servers**: Frontend at localhost:5173, Backend at localhost:8080
    
    **Test Scenario**: [describe what to verify]
    
    **Steps**:
    1. Navigate to http://localhost:5173
    2. [specific actions to perform]
    
    **Check in priority order** (stop when answer found):
    1. Browser console logs - look for errors, state transitions (🔄)
    2. Network requests - verify API calls and status codes
    3. Accessibility snapshot - check element presence
    4. Screenshot - ONLY if visual verification essential
    
    **Return**:
    - Pass/Fail result
    - Specific evidence (error messages, status codes, element presence)
    - Console action log if relevant (🔄 ACTION_TYPE entries)
    
    Do NOT include raw screenshots or full accessibility dumps.",
  description: "Test: [what being verified]"
)

When to Delegate vs Inline

Delegate to SubagentKeep Inline
Multi-page flowsSingle console check
Visual verification neededNetwork status check
Accessibility auditElement presence (single)
Error reproductionQuick state verification
Screenshot requiredReading console logs

Testing Priority (Token efficiency)

  1. Browser console logs - Check console messages for state transitions and errors
  2. VS Code terminal logs - Check terminal output for backend/frontend server logs
  3. Network requests - Inspect API calls and status codes
  4. Accessibility snapshot - Get DOM structure for element verification
  5. Screenshots - Visual verification (use sparingly, high token cost)

Key insight: Browser console shows React state changes (🔄 ACTION_TYPE), errors, and warnings. VS Code terminals show server logs and compilation output.

Workflow

Start servers in VS Code terminals (preferred - logs visible to AI agent):

# Run these VS Code tasks:
# - "Backend: ASP.NET Core API" (dotnet watch, port 8080)
# - "Frontend: React Vite" (npm run dev, port 5173)
# Or use compound task: "Start Dev (VS Code Terminals)"

Then test with Playwright MCP:

  1. Navigate to http://localhost:5173
  2. Check browser console for state transitions and errors
  3. Verify network requests for API calls
  4. Take accessibility snapshot for DOM validation

Check server logs:

  • Check VS Code terminal output for backend compilation and request logs
  • Backend terminal shows: request handling, errors, recompilation status
  • Frontend terminal shows: HMR updates, build warnings, Vite output

When to Test

  • After UI component or API endpoint changes
  • Before committing multi-step implementations
  • When user reports issues

Validation Checklist

  • Console shows expected actions (🔄 [timestamp] ACTION_TYPE)
  • No console errors/warnings
  • Network tab shows correct status codes (200/400/401/500)
  • DOM elements present in accessibility snapshot

State Logging (Dev Mode)

Each state change prints:

🔄 [HH:MM:SS] ACTION_TYPE
Action: { … }
Changes: { field: before → after }

Project-Specific: Key Test Scenarios

ScenarioWhat to Verify
Initial loadAuth redirect, agent metadata loads
Send messageUser message appears, streaming starts
StreamingText chunks append, no flicker
AnnotationsCitations render with links
Cancel streamInput re-enabled, status → idle
Error recoveryRetry button works, error clears

Project-Specific: Network Verification

EndpointSuccessFailure
POST /api/chat/stream200 + SSE events401 (auth), 400 (validation)
GET /api/agent/info200 + JSON metadata500 (agent not found)

Playwright MCP

CapabilityToken Cost
NavigateLow
Console logsLow
Click / TypeLow
Accessibility snapshotMedium
ScreenshotHigh

Use console logs for state verification. Use snapshots for element presence. Avoid screenshots unless visual check required.

Related Skills

  • validating-ui-features - Detailed test procedures for specific features
  • writing-typescript-code - Frontend patterns and state management
  • implementing-chat-streaming - SSE flow verification

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.