Generate

What This Skill Does

This skill generates production-ready Playwright tests from various inputs like user stories, URLs, component names, or feature descriptions. It leverages existing templates and codebase context to create well-structured and effective tests, saving developers time and ensuring consistent testing practices.

When to Use

• Generate a test for a user login flow.
• Create tests for a checkout process.
• Generate tests for a specific React component.
• Develop tests for a search page with filters.
• Create tests based on a user story description.
• Generate tests for API endpoints.

Key Features

• Parses user stories, component paths, and URLs to understand the testing target.
• Explores the codebase to gather context about existing tests and configurations.
• Selects appropriate test templates based on the testing target.
• Adapts templates with specific selectors, URLs, and data.
• Generates well-structured Playwright tests with describe blocks and assertions.
• Follows Playwright best practices for test structure and organization.

Manual Installation

Generate Playwright Tests

Generate production-ready Playwright tests from a user story, URL, component name, or feature description.

Input

$ARGUMENTS contains what to test. Examples: "user can log in with email and password" "the checkout flow" "src/components/UserProfile.tsx" "the search page with filters"

Steps

1. Understand the Target

Parse $ARGUMENTS to determine: User story: Extract the behavior to verify Component path: Read the component source code Page/URL: Identify the route and its elements Feature name: Map to relevant app areas

2. Explore the Codebase

Use the Explore subagent to gather context:

Read playwright.config.ts for testDir, baseURL, projects Check existing tests in testDir for patterns, fixtures, and conventions If a component path is given, read the component to understand its props, states, and interactions Check for existing page objects in pages/ Check for existing fixtures in fixtures/ Check for auth setup (auth.setup.ts or storageState config)

3. Select Templates

Check templates/ in this plugin for matching patterns:

Adapt the template to the specific app — replace {{placeholders}} with actual selectors, URLs, and data.

4. Generate the Test

Follow these rules:

Structure: import { test, expect } from '@playwright/test'; // Import custom fixtures if the project uses them

test.describe('Feature Name', () => { // Group related behaviors

test('should <expected behavior>', async ({ page }) => { // Arrange: navigate, set up state // Act: perform user action // Assert: verify outcome }); });

Locator priority (use the first that works): getByRole() — buttons, links, headings, form elements getByLabel() — form fields with labels getByText() — non-interactive text content getByPlaceholder() — inputs with placeholder text getByTestId() — when semantic options aren't available

Assertions — always web-first: // GOOD — auto-retries await expect(page.getByRole('heading')).toBeVisible(); await expect(page.getByRole('alert')).toHaveText('Success');

// BAD — no retry const text = await page.textContent('.msg'); expect(text).toBe('Success');

Never use: page.waitForTimeout() page.$(selector) or page.$$(selector) Bare CSS selectors unless absolutely necessary page.evaluate() for things locators can do

Always include: Descriptive test names that explain the behavior Error/edge case tests alongside happy path Proper await on every Playwright call baseURL-relative navigation (page.goto('/') not page.goto('http://...'))

5. Match Project Conventions

If project uses TypeScript → generate .spec.ts If project uses JavaScript → generate .spec.js with require() imports If project has page objects → use them instead of inline locators If project has custom fixtures → import and use them If project has a test data directory → create test data files there

6. Generate Supporting Files (If Needed)

Page object: If the test touches 5+ unique locators on one page, create a page object Fixture: If the test needs shared setup (auth, data), create or extend a fixture Test data: If the test uses structured data, create a JSON file in test-data/

7. Verify

Run the generated test:

npx playwright test <generated-file> --reporter=list

If it fails: Read the error Fix the test (not the app) Run again If it's an app issue, report it to the user

Output

Generated test file(s) with path Any supporting files created (page objects, fixtures, data) Test run result Coverage note: what behaviors are now testedGenerate Playwright Tests

Generate production-ready Playwright tests from a user story, URL, component name, or feature description.

Input

$ARGUMENTS contains what to test. Examples: "user can log in with email and password" "the checkout flow" "src/components/UserProfile.tsx" "the search page with filters"

Steps

1. Understand the Target

Parse $ARGUMENTS to determine: User story: Extract the behavior to verify Component path: Read the component source code Page/URL: Identify the route and its elements Feature name: Map to relevant app areas

2. Explore the Codebase

Use the Explore subagent to gather context:

Read playwright.config.ts for testDir, baseURL, projects Check existing tests in testDir for patterns, fixtures, and conventions If a component path is given, read the component to understand its props, states, and interactions Check for existing page objects in pages/ Check for existing fixtures in fixtures/ Check for auth setup (auth.setup.ts or storageState config)

3. Select Templates

Check templates/ in this plugin for matching patterns:

Adapt the template to the specific app — replace {{placeholders}} with actual selectors, URLs, and data.

4. Generate the Test

Follow these rules:

Structure: import { test, expect } from '@playwright/test'; // Import custom fixtures if the project uses them

test.describe('Feature Name', () => { // Group related behaviors

test('should <expected behavior>', async ({ page }) => { // Arrange: navigate, set up state // Act: perform user action // Assert: verify outcome }); });

Locator priority (use the first that works): getByRole() — buttons, links, headings, form elements getByLabel() — form fields with labels getByText() — non-interactive text content getByPlaceholder() — inputs with placeholder text getByTestId() — when semantic options aren't available

Assertions — always web-first: // GOOD — auto-retries await expect(page.getByRole('heading')).toBeVisible(); await expect(page.getByRole('alert')).toHaveText('Success');

// BAD — no retry const text = await page.textContent('.msg'); expect(text).toBe('Success');

Never use: page.waitForTimeout() page.$(selector) or page.$$(selector) Bare CSS selectors unless absolutely necessary page.evaluate() for things locators can do

Always include: Descriptive test names that explain the behavior Error/edge case tests a