e2e-test
npx machina-cli add skill cyberwalk3r/qa-toolkit/e2e-test --openclawE2E Test Writer (Playwright)
Generate Playwright E2E tests from natural-language scenarios. Read qa-artifacts/.qa-config.json for project context.
Input
Accept via $ARGUMENTS: scenario descriptions. Examples:
- "Test that a user can register, log in, and update their profile"
- "Test the shopping cart — add items, change quantities, remove items, checkout"
- "Verify the admin can ban a user and the user sees an error on next login"
Workflow
- Parse the scenario into discrete test steps
- Generate Playwright test with:
- Line-by-line comments explaining what each line does
- Descriptive test and describe block names
- Proper waiting strategies (no hard-coded waits)
- Meaningful assertions
- Use Page Object Model for reusable selectors
- Add setup/teardown for test data
- Include CI/CD config snippet if requested
Output Structure
// E2E Test: <scenario description>
// Generated by QA Toolkit on YYYY-MM-DD
//
// What this test does:
// 1. <step 1 description>
// 2. <step 2 description>
// 3. <step 3 description>
const { test, expect } = require('@playwright/test');
test.describe('Feature: <feature name>', () => {
test('should <expected behavior>', async ({ page }) => {
// Step 1: Navigate to the page
// This opens the browser and goes to the starting URL
await page.goto('/path');
// Step 2: Fill in the form
// We're entering a test email in the email field
await page.fill('[data-testid="email"]', 'test@example.com');
// Step 3: Submit and verify
// Click the submit button and wait for the response
await page.click('[data-testid="submit"]');
// Verify: Check that we see the success message
await expect(page.locator('.success')).toBeVisible();
});
});
Best Practices Applied
- Use
data-testidselectors (most stable) - Fallback: role-based selectors (
getByRole,getByLabel) - Last resort: CSS selectors
- Always wait for network idle or specific elements
- Use
test.step()for complex multi-step flows - Include error case tests alongside happy path
Run Script
Use scripts/run-test.js to execute: pass --help first to see options.
For Playwright patterns and advanced usage, read references/playwright-patterns.md.
Save
Save to qa-artifacts/e2e-tests/e2e-YYYY-MM-DD-<scenario>.spec.js
Suggested Next Steps
After generating E2E tests, suggest:
- "Run an accessibility audit on the same pages with
/qa-toolkit:accessibility."
Source
git clone https://github.com/cyberwalk3r/qa-toolkit/blob/main/skills/e2e-test/SKILL.mdView on GitHub Overview
Generates Playwright E2E test scaffolds from natural-language scenarios with line-by-line comments and a Page Object Model. It outputs descriptive, CI-ready test files that emphasize reusable selectors, proper waits, and meaningful assertions. This turns user stories into concrete, maintainable tests fast.
How This Skill Works
The tool parses the natural-language scenario into discrete steps, then generates a Playwright test file with descriptive describe/test names and line-by-line comments for each action. It applies the Page Object Model for reusable selectors, enforces proper waiting strategies, and adds setup/teardown scaffolding; it can include a CI/CD snippet if requested.
When to Use It
- When turning user stories into executable Playwright E2E tests from natural-language descriptions
- When you want well-commented scaffolds to guide test implementation and reviews
- When enforcing a Page Object Model with reusable selectors across tests
- When you need setup/teardown hooks and test data scaffolding
- When you want an optional CI/CD snippet to accompany the test file
Quick Start
- Step 1: Provide a natural-language scenario description via $ARGUMENTS
- Step 2: Review the generated Playwright test scaffold and adjust as needed
- Step 3: Save to qa-artifacts/e2e-tests/e2e-YYYY-MM-DD-<scenario>.spec.js
Best Practices
- Use data-testid selectors for stability and maintainability
- Fallback to role-based selectors (getByRole, getByLabel) when appropriate
- Last resort: CSS selectors only if no better option exists
- Always wait for network idle or specific elements rather than fixed delays
- Use test.step() for complex flows and include adjacent error-case tests
Example Use Cases
- Test that a user can register, log in, and update their profile
- Test the shopping cart — add items, change quantities, remove items, checkout
- Verify the admin can ban a user and the user sees an error on next login
- Test password reset flow via email link
- Test profile picture upload and validation