Token导航 LogoToken导航

Agent Skill · 研究检索

playwright-testing(Playwright 测试)

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

playwright-testing 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为操作浏览器;许可证为 MIT,第三方扫描已通过,按安装量在研究检索类的 73,675 个 Skill 里排第 50,488。

总安装 612周安装 26GitHub Stars 2下载 214核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:playwright-testing(Playwright 测试)
来源仓库:https://github.com/mhagrelius/dotfiles
仓库路径:skills/playwright-testing
安装命令:
npx skills add https://github.com/mhagrelius/dotfiles --skill playwright-testing
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/mhagrelius/dotfiles --skill playwright-testing

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

playwright-testing 用于辅助测试设计、自动化测试、用例整理和回归验证,适合编写单元测试、端到端测试和测试计划。适用于测试开发、自动化验证和问题定位等测试类任务。帮助 Agent 编写测试用例、分析失败日志和制定测试计划。

安装命令:npx skills add https://github.com/mhagrelius/dotfiles --skill playwright-testing 使用时需确认项目测试框架和运行命令,避免为了通过测试而改坏真实逻辑,涉及浏览器时应区分本地模拟和测试环境。

来源仓库内路径:skills/playwright-testing

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/mhagrelius/dotfiles --skill playwright-testing;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要操作浏览器,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

playwright-testing 怎么安装?

在终端执行 npx skills add https://github.com/mhagrelius/dotfiles --skill playwright-testing。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

playwright-testing 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

playwright-testing 需要什么权限?

权限级别是操作浏览器。该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

playwright-testing 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

playwright-testing 用的人多吗?

公开数据是累计安装 612 次,近一周安装 26 次,下载 214 次,GitHub 2 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

playwright-testing 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
playwright-testing

Playwright 测试 · 本页

6122操作浏览器MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Playwright Testing

Write reliable, fast, maintainable Playwright tests for SPAs.

Contents

Core principle: Test what users see and do. If a user can't find an element by its role or text, neither should your test.

Quality layers: Reliable (no flakes) → Fast (parallel, minimal waits) → Maintainable (survives refactors)

Philosophy: User-centric locators by default. Implementation details (test-ids, CSS selectors) are escape hatches, not first choices.

The Process

  1. Identify: What user behavior are we testing?
  2. Locate: Find elements the way users would (role, label, text)
  3. Act: Perform user actions (click, fill, navigate)
  4. Assert: Verify visible outcomes, not internal state
  5. Stabilize: Handle async, add appropriate waits

Red Flags - STOP

  • page.locator('.btn-primary') - CSS class selectors
  • page.waitForTimeout(1000) - arbitrary sleeps
  • page.locator('[data-testid="x"]') as first choice
  • Testing component internals instead of user outcomes
  • Long test files with no page objects or fixtures

Locator Priority

digraph locator_priority {
    rankdir=TB;
    node [shape=box];

    "Need to find element" [shape=diamond];
    "Has accessible role?" [shape=diamond];
    "Has label/placeholder?" [shape=diamond];
    "Has visible text?" [shape=diamond];
    "getByRole" [style=filled fillcolor=lightgreen];
    "getByLabel/getByPlaceholder" [style=filled fillcolor=lightgreen];
    "getByText" [style=filled fillcolor=lightgreen];
    "getByTestId" [style=filled fillcolor=lightyellow];

    "Need to find element" -> "Has accessible role?";
    "Has accessible role?" -> "getByRole" [label="yes"];
    "Has accessible role?" -> "Has label/placeholder?" [label="no"];
    "Has label/placeholder?" -> "getByLabel/getByPlaceholder" [label="yes"];
    "Has label/placeholder?" -> "Has visible text?" [label="no"];
    "Has visible text?" -> "getByText" [label="yes"];
    "Has visible text?" -> "getByTestId" [label="no (last resort)"];
}
PriorityLocatorWhen to UseExample
1stgetByRoleButtons, links, inputs, headings, listsgetByRole('button', {name: 'Submit'})
2ndgetByLabelForm inputs with labelsgetByLabel('Email address')
3rdgetByPlaceholderInputs with placeholder textgetByPlaceholder('Search...')
4thgetByTextStatic text content, paragraphsgetByText('Welcome back')
5thgetByAltTextImagesgetByAltText('Company logo')
LastgetByTestIdDynamic content, no semantic meaninggetByTestId('total-price')

Role Examples

// Buttons
page.getByRole('button', { name: 'Save changes' })
page.getByRole('button', { name: /submit/i })  // regex for flexibility

// Links
page.getByRole('link', { name: 'View profile' })

// Form inputs
page.getByRole('textbox', { name: 'Username' })
page.getByRole('checkbox', { name: 'Remember me' })
page.getByRole('combobox', { name: 'Country' })

// Structure
page.getByRole('heading', { name: 'Dashboard', level: 1 })
page.getByRole('list').getByRole('listitem')
page.getByRole('dialog', { name: 'Confirm deletion' })

// Tables
page.getByRole('table').getByRole('row', { name: /john/i })

Disambiguating Multiple Matches

// Specify which match you want
await page.getByRole('button', { name: 'Delete' }).first().click();
await page.getByRole('listitem').last().click();
await page.getByRole('row').nth(2).click();  // 0-indexed

// Filter by content or child elements
await page.getByRole('listitem').filter({ hasText: 'John' }).click();
await page.getByRole('listitem').filter({
    has: page.getByRole('button', { name: 'Edit' })
}).click();

// Chain locators to scope
await page.getByRole('dialog').getByRole('button', { name: 'Confirm' }).click();

Locator Anti-patterns

BadWhyGood
.locator('.submit-btn')Breaks on class renamegetByRole('button', {name: 'Submit'})
.locator('#email-input')Coupled to implementationgetByLabel('Email')
.locator('div > span:nth-child(2)')Extremely brittlegetByText('...') or add test-id
getByTestId everywhereMisses accessibility bugsUse semantic locators first
Unscoped locator with multiple matchesFlaky, might click wrong elementUse .first(), .filter(), or scope with parent

Waiting & Async

Playwright auto-waits for most actions. Don't add manual waits unless you have a specific reason.

digraph waiting {
    rankdir=TB;
    node [shape=box];

    "What are you waiting for?" [shape=diamond];
    "Element to appear" [shape=diamond];
    "Auto-wait (built-in)" [style=filled fillcolor=lightgreen];
    "expect + toBeVisible" [style=filled fillcolor=lightgreen];
    "waitForResponse" [style=filled fillcolor=lightyellow];
    "waitForURL" [style=filled fillcolor=lightyellow];
    "NEVER waitForTimeout" [style=filled fillcolor=lightpink];

    "What are you waiting for?" -> "Auto-wait (built-in)" [label="clicking/filling"];
    "What are you waiting for?" -> "Element to appear" [label="element"];
    "What are you waiting for?" -> "waitForResponse" [label="API call"];
    "What are you waiting for?" -> "waitForURL" [label="navigation"];
    "Element to appear" -> "expect + toBeVisible" [label="use assertion"];
    "Element to appear" -> "NEVER waitForTimeout" [label="don't guess"];
}

Built-in Auto-Waiting

These actions auto-wait - no manual wait needed:

// All of these wait automatically for element to be actionable
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email').fill('test@example.com');
await page.getByRole('checkbox').check();
await page.getByRole('combobox').selectOption('US');

Explicit Waits (When Needed)

// Wait for element state (prefer assertions)
await expect(page.getByText('Success')).toBeVisible();
await expect(page.getByRole('button')).toBeEnabled();
await expect(page.getByRole('list')).not.toBeEmpty();

// Wait for navigation
await page.waitForURL('**/dashboard');
await page.waitForURL(url => url.searchParams.has('token'));

// Wait for API response (useful for loading states)
await page.getByRole('button', { name: 'Load data' }).click();
await page.waitForResponse(resp =>
    resp.url().includes('/api/data') && resp.status() === 200
);

// Wait for network idle (use sparingly - can be slow)
await page.waitForLoadState('networkidle');

// Wait for specific request to complete before asserting
const responsePromise = page.waitForResponse('/api/users');
await page.getByRole('button', { name: 'Refresh' }).click();
await responsePromise;
await expect(page.getByRole('list')).toContainText('John');

// Promise.all pattern - click and wait simultaneously
await Promise.all([
    page.waitForResponse(resp => resp.url().includes('/api/data')),
    page.getByRole('button', { name: 'Submit' }).click()
]);

Waiting Anti-patterns

BadWhyGood
waitForTimeout(2000)Arbitrary, slow, still flakyWait for specific condition
waitForTimeout(100) in loopPolling manuallyUse expect with auto-retry
waitForLoadState('networkidle') everywhereSlow, unreliable with pollingWait for specific response
No wait + immediate assertRace conditionexpect auto-retries assertions

Assertion Auto-Retry

Playwright assertions auto-retry until timeout. Use this instead of manual waits:

// BAD: manual wait then check
await page.waitForTimeout(1000);
const text = await page.getByTestId('status').textContent();
expect(text).toBe('Complete');

// GOOD: auto-retrying assertion
await expect(page.getByText('Complete')).toBeVisible();

Soft Assertions

Use expect.soft() to continue testing after assertion failure (collect multiple failures):

test('validates all form fields', async ({ page }) => {
    await page.goto('/profile');

    // Soft assertions don't stop the test - useful for checking multiple things
    await expect.soft(page.getByLabel('Name')).toHaveValue('John');
    await expect.soft(page.getByLabel('Email')).toHaveValue('john@example.com');
    await expect.soft(page.getByLabel('Phone')).toHaveValue('555-1234');

    // Test continues even if some assertions fail
    // All failures reported at end
});

Handling Overlays and Popups

Use addLocatorHandler when overlays might interfere with test actions:

// Setup handler for cookie consent popup
await page.addLocatorHandler(
    page.getByRole('dialog', { name: 'Cookie consent' }),
    async () => {
        await page.getByRole('button', { name: 'Accept' }).click();
    }
);

// Now write test normally - handler auto-dismisses popup if it appears
await page.goto('/dashboard');
await page.getByRole('button', { name: 'Settings' }).click();

Test Structure

For page objects, fixtures, and test organization, see reference/structure.md.

Quick tips:

  • Page objects encapsulate interactions, not assertions
  • Fixtures handle common setup/teardown
  • One behavior per test
  • Use test.describe for grouping related tests

Performance

For parallel execution, auth optimization, and API shortcuts, see reference/performance.md.

Quick tips:

  • Reuse auth state via storageState
  • Create test data via API, not UI
  • Use fullyParallel: true
  • Avoid waitForLoadState('networkidle')

Debugging

For debug mode, traces, and common scenarios, see reference/debugging.md.

Quick tips:

  • npx playwright test --debug for local debugging
  • View traces for CI failures: npx playwright show-trace trace.zip
  • Use await page.pause() to stop and inspect

CI Configuration

For GitHub Actions, sharding, and CI-specific config, see reference/ci.md.

Quick tips:

  • forbidOnly:!!process.env.CI prevents test.only in CI
  • retries: 2 for CI to handle transient failures
  • Upload artifacts for debugging failures

Quality Checklist

Create TodoWrite items for each applicable check before finalizing tests.

Layer 1: Reliable (No Flakes)

  • No waitForTimeout() calls - using condition-based waits
  • Assertions use expect() with auto-retry, not manual checks
  • Tests are independent - no shared state between tests
  • Waiting for specific API responses, not networkidle
  • Locators are specific enough (single element match)
  • Tests pass consistently (run 5x locally before committing)

Layer 2: Fast

  • Authentication reused via storageState
  • Test data created via API, not UI
  • Tests run in parallel (fullyParallel: true)
  • No unnecessary waitForLoadState('networkidle')
  • Heavy setup in fixtures, not repeated per test
  • Sharding configured for large test suites

Layer 3: Maintainable

  • Locators use roles/labels, not CSS selectors
  • Page objects encapsulate interactions
  • Test names describe user action + expected outcome
  • One behavior per test - not testing multiple things
  • Fixtures handle common setup/teardown
  • No magic strings - constants for repeated values

Common Patterns Reference

NeedPattern
Authenticated userstorageState fixture
Test data setupAPI calls in beforeEach or fixture
Wait for data loadwaitForResponse('/api/...')
Click + wait for responsePromise.all([waitForResponse(...), click()])
Multiple similar teststest.describe + parameterized data
Slow operationIncrease timeout for specific test
Modal/dialoggetByRole('dialog') then scope within
Dropdown selectiongetByRole('combobox').selectOption()
File uploadsetInputFiles() on file input
Hover menulocator.hover() then click revealed item
Drag and droplocator.dragTo(target)
iframesframeLocator() then scope within
New tab/windowpage.waitForEvent('popup')
Multiple matches.first(), .last(), .nth(n), .filter()
Check multiple thingsexpect.soft() for non-blocking assertions
Dismiss popups/overlaysaddLocatorHandler()

When to Add data-testid

Use data-testid as escape hatch when:

  • Element has no semantic role (decorative container)
  • Dynamic content with no stable text (generated IDs, prices)
  • Multiple identical elements where position matters
  • Third-party components without accessible markup
// Acceptable: price that changes dynamically
<span data-testid="cart-total">{formatCurrency(total)}</span>
page.getByTestId('cart-total')

// Still prefer scoping with semantic locators
page.getByRole('region', { name: 'Cart' }).getByTestId('total')

Quick Reference Commands

# Run all tests
npx playwright test

# Run specific file
npx playwright test login.spec.ts

# Run tests matching name
npx playwright test -g "login"

# Run in headed mode
npx playwright test --headed

# Debug mode with inspector
npx playwright test --debug

# Update snapshots
npx playwright test --update-snapshots

# Generate test from recording
npx playwright codegen localhost:3000

# Show last HTML report
npx playwright show-report

平台分布

Claude Code

28.95%
按下载量换算62

OpenCode

22.55%
按下载量换算48

Antigravity

17.47%
按下载量换算37

Codex

13.06%
按下载量换算28

Gemini CLI

6.99%
按下载量换算15

windsurf

3.17%
按下载量换算7

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills