test

What this skill does

# Test — Verify Your Deployment

You are running end-to-end tests against the deployed application using the Playwright MCP server to automate a real browser.

## When This Skill Activates
- User wants to test the deployed application
- User asks "does it work?" or "let's verify the deployment"
- User says "test my site" or "check my deployment"
- Deployment just completed and user wants verification

## Prerequisites
- Application is deployed (`.migration/outputs.json` exists with URLs)
- If not deployed, suggest deploying first

## What To Do

### Phase 1: Plan

Read `.migration/outputs.json` to get deployed URLs, then show the test plan:

1. **Explain what we'll test:**
   "I'll open a real browser and test your deployed app. Playwright automates the browser — clicking buttons, filling forms, and checking results — just like a real user would."

2. **Test plan based on what's deployed:**

   **Core Tests (always run):**
   - Site loads successfully (CloudFront URL returns 200)
   - Main page renders correctly
   - No console errors

   **API Tests (if API deployed):**
   - Each API endpoint returns expected data
   - POST endpoints create data correctly
   - Error handling works (invalid inputs return proper errors)

   **Auth Tests (if Cognito deployed):**
   - Sign-up form works
   - Sign-in form works
   - Protected routes reject unauthenticated requests
   - Protected routes work after sign-in

   **Database Tests (if DynamoDB deployed):**
   - Create, read, update, delete operations work
   - Data persists across requests

### Phase 2: Execute

Use the Playwright MCP server to run each test:

1. **Navigate to the site:**
   - Use `browser_navigate` to open the CloudFront URL
   - Take a snapshot to verify it loaded
   - Check for console errors with `browser_console_messages`

2. **Test the frontend:**
   - Use `browser_snapshot` to check the page content
   - Verify key elements are present
   - Take a screenshot for the user

3. **Test API endpoints:**
   - Use `browser_navigate` to call API endpoints directly
   - Or use `browser_evaluate` to make fetch calls from the browser
   - Verify response status codes and data

4. **Test auth flow (if applicable):**
   - Navigate to sign-up page
   - Fill in registration form with test credentials using `browser_fill_form`
   - Submit and verify success
   - Navigate to sign-in page
   - Fill in login form
   - Verify authenticated state
   - Test a protected API route

5. **Test CRUD operations (if applicable):**
   - Create a new item through the UI or API
   - Read it back
   - Update it
   - Delete it
   - Verify it's gone

### Phase 3: Report

Create a test results summary:

```markdown
# Test Results — [Date]

## Summary
- Passed: [N] tests
- Failed: [N] tests
- Warnings: [N]

## Details

### Frontend
- Site loads at [URL]
- No console errors
- Main page renders correctly

### API
- GET /api/items returns data
- POST /api/items creates item
- DELETE /api/items/:id returns 500 — [details]

### Auth (if tested)
- Sign-up works
- Sign-in works
- Protected routes require auth

### Screenshots
[Include screenshots of key pages]
```

For any failures:
- Explain what went wrong in simple terms
- Suggest specific fixes
- Offer to help fix the issues

Save results to `.migration/test-results.md`

### Phase 4: Next Steps

- If all tests pass: "Everything works! Your app is live and functional."
- If some tests fail: "Let's fix these issues. The most important one is [X] because [reason]."
- Remind about cleanup: "When you're done, ask me to tear down the resources to stop any costs."

## Important Notes

### Playwright MCP Usage
- Use `browser_snapshot` (accessibility tree) for checking content — more reliable than screenshots
- Use `browser_take_screenshot` for visual evidence to show the user
- Use `browser_console_messages` to catch JavaScript errors
- Use `browser_network_requests` to debug API issues
- Always close the browser when done with `browser_close`

### Test Data
- Use clearly fake data for testing (e.g., [email protected])
- Clean up test data after testing if possible
- Don't use real email addresses for Cognito sign-up tests

### Timeouts
- CloudFront may take a few minutes to propagate after deployment
- Lambda cold starts may cause first request to be slow
- If a test fails due to timeout, try once more before reporting failure