Generate

alirezarezvani/claude-skills/engineering-team/playwright-pro/skills/generate

作者 alirezarezvani19392f7a0826無授權條款27K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫5 週前更新

Generate Playwright tests. Use when user says "write tests", "generate tests", "add tests for", "test this component", "e2e test", "create test for", "test this page", or "test this feature".

AI 產生的概覽

依據使用者故事、URL、元件或功能描述,產生可直接使用的 Playwright 端對端測試。

功能
此技能會把描述的行為、頁面、元件路徑或功能轉換成 Playwright 測試檔案。它會先探查程式庫中的設定、現有測試、頁面物件、fixture 與驗證設定,再挑選相符的範本,並以真實的選擇器、URL 和資料加以調整。它遵循定位器優先順序與 web-first 斷言規則,配合 TypeScript 或 JavaScript 等專案慣例,並可建立搭配的頁面物件、fixture 或測試資料。接著它會執行產生的測試,並回報檔案路徑、執行結果與涵蓋範圍說明。
適用情境
當被要求為元件、頁面或功能撰寫、產生或新增測試,或被要求進行端對端測試時使用。它適合已採用 Playwright、且新測試需要遵循現有慣例的專案。
執行需求
需要一個使用 @playwright/test 並具備 playwright.config.ts 的 Playwright 專案,以及執行 npx playwright test 的能力。它會讀取程式庫,可能需要存取範本以及現有的頁面物件、fixture 與驗證設定。它不附帶指令碼,僅為指示。

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:

If testing...Load template from
Login/auth flow../pw/templates/auth/login.md
CRUD operationstemplates/crud/
Checkout/paymenttemplates/checkout/
Search/filter UItemplates/search/
Form submissiontemplates/forms/
Dashboard/datatemplates/dashboard/
Settings pagetemplates/settings/
Onboarding flowtemplates/onboarding/
API endpointstemplates/api/
Accessibilitytemplates/accessibility/

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

4. Generate the Test

Follow these rules:

Structure:

typescript
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):

  1. getByRole() — buttons, links, headings, form elements
  2. getByLabel() — form fields with labels
  3. getByText() — non-interactive text content
  4. getByPlaceholder() — inputs with placeholder text
  5. getByTestId() — when semantic options aren't available

Assertions — always web-first:

typescript
// 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) 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:

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

If it fails:

  1. Read the error
  2. Fix the test (not the app)
  3. Run again
  4. 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

來源與署名

來源:alirezarezvani/claude-skills位於engineering-team/playwright-pro/skills/generate提交19392f7

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架