generate
alirezarezvani/claude-skills
生成 Playwright 测试。当用户说“编写测试”、“生成测试”、“为……添加测试”、“测试此组件”、“端到端测试”、 “为……创建测试”、“测试此页面”或“测试此功能”时使用。
...展开全部关于 generate
generate 技能可根据用户故事、URL、组件路径或功能描述,生成可直接投入生产的 Playwright 端到端测试。 它解决了手动编写可靠且符合约定规范的浏览器测试所面临的问题:在生成任何内容之前,该技能会探索现有项目以了解其测试目录、基础 URL、测试数据和页面对象约定,因此生成的内容完全契合目标代码库,而非套用通用模板。
该工作流会解析测试内容,使用“探索”子代理读取 Playwright 配置和现有测试,选择匹配的模板(身份验证、CRUD、结账、搜索、表单、仪表盘、设置、入门、API、无障碍访问),并使用真实的选择器和数据对其进行适配。Generate 生成的测试需遵循严格的质量规范:定位器优先级顺序应优先使用 getByRole、getByLabel 及其他语义定位器,而非裸 CSS;采用以 Web 为先的自动重试断言;并明确禁止使用 waitForTimeout、page.$ 选择器以及不必要的 page.evaluate 等反模式。 它符合项目关于 TypeScript 与 JavaScript、页面对象及测试数据的规范,并在必要时可 generate 支持页面对象、测试数据和测试数据文件。最后,它使用 Playwright CLI 运行 generate d 测试,并针对失败情况进行迭代处理。
该工具面向使用 Playwright 且希望以自身项目风格实现一致、可维护的端到端(e2e)测试覆盖的 Web 开发人员和质量保证(QA)工程师 generate d。 典型用例包括测试登录和结账流程、表单验证、搜索和筛选界面以及组件行为。该技能附带 SKILL.md 文件和 patterns.md 文件,其中收录了身份验证、CRUD 操作及验证流程的具体测试示例。
常见问题
它接受哪些输入?
用户故事、组件文件路径、页面或 URL,以及功能名称——例如“用户可以使用邮箱和密码登录”或“src/components/UserProfile.tsx”。
它强制采用哪种定位器和断言风格?
它优先使用语义定位器(按顺序为 getByRole、getByLabel、getByText、getByPlaceholder、getByTestId),并始终采用“Web 优先”的自动重试断言,而非手动文本提取。
它会避免哪些反模式?
它绝不使用 page.waitForTimeout()、page.$/page.$$ 选择器、裸 CSS 选择器(除非无法避免),也不会在定位器可处理的情况下使用 page.evaluate()。
它会验证自己编写的测试吗?
是的——它会通过 'npx playwright test
它会符合我项目的规范吗?
它会读取 playwright.config.ts 文件和现有测试,以匹配 TypeScript 与 JavaScript 的差异、现有的页面对象、自定义测试环境以及 test-data 目录。
所有文件
2 个文件 SKILL.md 4.4 KB Viewpatterns.md 5.7 KB ViewGenerate 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.tsfortestDir,baseURL,projects - Check existing tests in
testDirfor 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.tsorstorageStateconfig)
3. Select Templates
Check templates/ in this plugin for matching patterns:
| If testing... | Load template from |
|---|---|
| Login/auth flow | ../pw/templates/auth/login.md |
| CRUD operations | templates/crud/ |
| Checkout/payment | templates/checkout/ |
| Search/filter UI | templates/search/ |
| Form submission | templates/forms/ |
| Dashboard/data | templates/dashboard/ |
| Settings page | templates/settings/ |
| Onboarding flow | templates/onboarding/ |
| API endpoints | templates/api/ |
| Accessibility | templates/accessibility/ |
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 themtest.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 elementsgetByLabel()— form fields with labelsgetByText()— non-interactive text contentgetByPlaceholder()— inputs with placeholder textgetByTestId()— when semantic options aren't available
Assertions — always web-first:
// GOOD — auto-retriesawait expect(page.getByRole('heading')).toBeVisible();await expect(page.getByRole('alert')).toHaveText('Success');// BAD — no retryconst text = await page.textContent('.msg');expect(text).toBe('Success');
Never use:
page.waitForTimeout()page.$(selector)orpage.$$(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
awaiton every Playwright call baseURL-relative navigation (page.goto('/')notpage.goto('http://...'))
5. Match Project Conventions
- If project uses TypeScript → generate
.spec.ts - If project uses JavaScript → generate
.spec.jswithrequire()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 tested
安装 generate
下载技能文件并将其解压到 .claude/skills/ 目录下。
下载ZIP克隆仓库并复制技能文件到您的项目中。
git clone https://github.com/alirezarezvani/claude-skills/blob/main/engineering-team/playwright-pro/skills/generate/SKILL.md # Copy SKILL.md to your .claude/skills/ directory
复制





首页
