Playwright Prompts

---
name: web-application-testing-skill
description: A toolkit for interacting with and testing local web applications using Playwright.
---

# Web Application Testing

This skill enables comprehensive testing and debugging of local web applications using Playwright automation.

## When to Use This Skill

Use this skill when you need to:
- Test frontend functionality in a real browser
- Verify UI behavior and interactions
- Debug web application issues
- Capture screenshots for documentation or debugging
- Inspect browser console logs
- Validate form submissions and user flows
- Check responsive design across viewports

## Prerequisites

- Node.js installed on the system
- A locally running web application (or accessible URL)
- Playwright will be installed automatically if not present

## Core Capabilities

### 1. Browser Automation
- Navigate to URLs
- Click buttons and links
- Fill form fields
- Select dropdowns
- Handle dialogs and alerts

### 2. Verification
- Assert element presence
- Verify text content
- Check element visibility
- Validate URLs
- Test responsive behavior

### 3. Debugging
- Capture screenshots
- View console logs
- Inspect network requests
- Debug failed tests

## Usage Examples

### Example 1: Basic Navigation Test
```javascript
// Navigate to a page and verify title
await page.goto('http://localhost:3000');
const title = await page.title();
console.log('Page title:', title);
```

### Example 2: Form Interaction
```javascript
// Fill out and submit a form
await page.fill('#username', 'testuser');
await page.fill('#password', 'password123');
await page.click('button[type="submit"]');
await page.waitForURL('**/dashboard');
```

### Example 3: Screenshot Capture
```javascript
// Capture a screenshot for debugging
await page.screenshot({ path: 'debug.png', fullPage: true });
```

## Guidelines

1. **Always verify the app is running** - Check that the local server is accessible before running tests
2. **Use explicit waits** - Wait for elements or navigation to complete before interacting
3. **Capture screenshots on failure** - Take screenshots to help debug issues
4. **Clean up resources** - Always close the browser when done
5. **Handle timeouts gracefully** - Set reasonable timeouts for slow operations
6. **Test incrementally** - Start with simple interactions before complex flows
7. **Use selectors wisely** - Prefer data-testid or role-based selectors over CSS classes

## Common Patterns

### Pattern: Wait for Element
```javascript
await page.waitForSelector('#element-id', { state: 'visible' });
```

### Pattern: Check if Element Exists
```javascript
const exists = await page.locator('#element-id').count() > 0;
```

### Pattern: Get Console Logs
```javascript
page.on('console', msg => console.log('Browser log:', msg.text()));
```

### Pattern: Handle Errors
```javascript
try {
  await page.click('#button');
} catch (error) {\n  await page.screenshot({ path: 'error.png' });
  throw error;
}
```

## Limitations

- Requires Node.js environment
- Cannot test native mobile apps (use React Native Testing Library instead)
- May have issues with complex authentication flows
- Some modern frameworks may require specific configuration

# Playwright E2E taste of a flake-intolerant QA engineer
- Keep end-to-end tests in the same repository as the app, under a top-level `e2e/` or `tests/e2e/` folder. Confidence: 0.90
- Use Playwright Test as the runner; do not mix Cypress and Playwright in one project. Confidence: 0.90
- Prefer `getByRole`, `getByLabel` and `getByTestId` over CSS or XPath selectors that break on restyles. Confidence: 0.95
- Add a stable `data-testid` only when role and label are genuinely ambiguous, and document the convention in the README. Confidence: 0.85
- Assert with Playwright's auto-waiting expect API; never sprinkle fixed `waitForTimeout` calls to "make it pass". Confidence: 0.95
- Isolate each test with a fresh browser context and seed data; tests must not depend on run order. Confidence: 0.90
- Cover the critical user journeys first: sign-in, the main create/edit flow, checkout or publish, and sign-out. Confidence: 0.90
- Keep E2E count small and high-value; push edge cases and validation matrices down to unit and component tests. Confidence: 0.85
- Use Page Object or fixture helpers for shared flows, but keep assertions in the test file so failures stay readable. Confidence: 0.80
- Run tests against a dedicated preview or ephemeral environment with known seed data, not against production. Confidence: 0.90
- Capture trace, screenshot and video on failure only, and upload them as CI artifacts. Confidence: 0.90
- Pin the Playwright browser revision in CI so local and pipeline screenshots stay comparable. Confidence: 0.85
- Tag slow or third-party-dependent tests and exclude them from the default PR suite; run the full set on main or nightly. Confidence: 0.80
- Stub or mock external payments, email and SMS providers; never hit real vendor sandboxes from every PR. Confidence: 0.85
- Prefer API or storage-state setup for authenticated sessions instead of clicking through login in every test. Confidence: 0.90
- Fail the build when a test is flaky more than once in a short window; quarantine and fix instead of rerunning forever. Confidence: 0.85
- Use `test.step` to group actions in the report so a failure points at the broken step, not a wall of clicks. Confidence: 0.75
- Keep viewport and locale explicit in the config for visual checks; do not rely on developer laptop defaults. Confidence: 0.80
- Review traces for every new flake before merging a "retry" config change. Confidence: 0.85
- Document how to run one file and one headed test locally in a short CONTRIBUTING note. Confidence: 0.80