Token导航 LogoToken导航

Agent Skill · 研究检索

testing-e2e(测试端到端)

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

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

总安装 96周安装 4GitHub Stars 公开资料未说明下载 32核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add agdev/claude-code --skill "testing-e2e"

这个 Skill 是做什么的

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

专注于端到端(E2E)测试的支持。协助构建完整的用户流程测试用例。testing-e2e 属于研究检索类 Skill,可作为该场景下的辅助能力补充。可用于验证系统整体功能和交互逻辑。需配置合适的测试环境和模拟数据。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。执行前应评估对生产系统的影响风险。

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

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add agdev/claude-code --skill "testing-e2e";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

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

常见问题

6 条

testing-e2e 怎么安装?

在终端执行 npx skills add agdev/claude-code --skill "testing-e2e"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

testing-e2e 支持哪些 AI 工具?

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

testing-e2e 需要什么权限?

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

testing-e2e 是免费的吗?

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

testing-e2e 用的人多吗?

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

testing-e2e 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

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

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 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调用外部服务未明确有提醒
testing-e2e

测试端到端 · 本页

96—操作浏览器MIT未收录

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

SKILL.md 原文

name
testing-e2e
description
Expert guidance for writing resilient end-to-end tests that span multiple processes and components. Use this skill when reviewing, writing, or refactoring system-wide e2e tests. Covers user-facing scenarios, helper functions, data factories, ARIA-based selectors, and auto-retriable assertions. NOT for unit/integration tests - use testing-unit-integration skill instead. See references/playwright-resilience.md for detailed selector patterns.

End-to-End Testing Best Practices

Expert guidance for system-wide e2e tests spanning multiple processes.

Scope: System-wide end-to-end tests only. NOT for unit, integration, or component tests with mocked backends - use testing-unit-integration skill instead.

Note: E2E tests are complex, slow, and limited in quantity - relaxed readability standards and less stringent best practices are acceptable compared to unit tests.

Core Rules

Self-Contained Tests (Critical)

  • A.8 Each test is self-contained, never relies on other tests' state or artifacts
  • A.11 Start with fresh dedicated data created in beforeEach or during test
  • A.14 Test real user scenarios, simulate actual user behavior
  • A.35 Implement comprehensive test data management with automatic cleanup

User-Facing Locators (Critical)

  • A.17 Only ARIA-based locators: getByRole, getByLabel, getByText
  • A.17 NO CSS selectors, test IDs, xpath, $, or implementation-specific locators
  • A.40 No positional selectors: nth(i), first(), last()

Boundaries

  • A.23 Only visit and test within application boundaries
  • A.48 Don't approach or assert on external systems - assert navigation happened

Structure

  • A.5 Title summarizes flow with stakeholder, action, expectations
  • A.26 Max 15 statements - encapsulate multi-step operations in helper functions

Helper Functions Pattern

Each helper represents a meaningful part of user's journey, not low-level interactions:

// ✅ GOOD - Semantic helpers
async function loginAsAdmin(page: Page): Promise<void>
async function addProductToCart(page: Page, product: Product): Promise<void>
async function completeCheckout(page: Page): Promise<OrderDetails>
async function verifyOrderConfirmationEmailSent(email: string, order: OrderDetails): Promise<void>

// ❌ BAD - Low-level interactions exposed
async function clickButton(page: Page, name: string): Promise<void>
async function fillInput(page: Page, selector: string, value: string): Promise<void>

Waiting Strategies

  • A.44 No time-based waiting: setTimeout, page.waitForTimeout()
  • A.44 No waitForSelector - couples test to implementation
  • A.20 Use auto-retriable assertions (web-first assertions):
// ❌ BAD
await page.waitForTimeout(3000)
await page.waitForSelector('.form-loaded')

// ✅ GOOD - Auto-retriable assertions
await expect(page.getByText(/success/i)).toBeVisible()
await expect(page).toHaveURL(/\/dashboard/)

Data Factories

  • A.52 Data from factory files with buildEntity() functions
  • A.52 Factories return defaults but allow field overrides
  • A.55 Use meaningful domain data with faker, not dummy values
import { faker } from "@faker-js/faker";
import { Customer } from "../types";

export function buildCustomer(overrides: Partial<Customer> = {}): Customer {
  return {
    email: faker.internet.email(),
    name: faker.person.fullName(),
    address: faker.location.streetAddress(),
    ...overrides,
  };
}

Assertions

  • A.58 No custom coding, loops, Array.prototype - use built-in expect APIs
  • A.62 Minimal assertions - one strong assertion catches all issues
  • A.65 Use matchers that show full diff on failure

Strong Assertions

// ❌ WEAK - Multiple redundant assertions
expect(response).not.toBeNull()
expect(Array.isArray(response)).toBe(true)
expect(response.length).toBe(2)

// ✅ STRONG - Single assertion catches all
expect(response).toEqual([{id: '123'}, {id: '456'}])

Navigation Testing

E2E tests catch navigation bugs that mocked unit/integration tests miss.

  • A.50 Assert navigation OUTCOME (destination page renders), not that navigate() was called
  • A.52 Test router config must match production router - use real routes, not mocked
  • A.54 Use route constants, not hardcoded path strings - prevents typos and drift
  • A.56 Verify URL changed to expected value after navigation actions
  • A.58 E2E tests are the safety net - they catch contract and navigation bugs that mocked tests miss
// ❌ BAD - Testing that navigate function was called (implementation detail)
expect(mockNavigate).toHaveBeenCalledWith('/users/123');

// ❌ BAD - Hardcoded path string (typos won't be caught)
await page.goto('/usres/123');  // Typo! Would fail silently in unit test

// ✅ GOOD - Assert the OUTCOME (user sees the page)
await expect(page.getByRole('heading', { name: /user profile/i })).toBeVisible();

// ✅ GOOD - Verify URL changed
await expect(page).toHaveURL(/\/users\/\d+/);

// ✅ GOOD - Use route constants (from shared constants file)
import { ROUTES } from '@/constants/routes';
await page.goto(ROUTES.USER_PROFILE.replace(':id', '123'));

Why E2E Catches What Unit Tests Miss

Bug TypeUnit Test (Mocked)E2E Test
Route typo in navigate('/usres')❌ Passes (mock doesn't validate)✅ Fails (404 page)
Route param mismatch (email vs id)❌ Passes (mock accepts anything)✅ Fails (wrong page loads)
Missing route in router config❌ Passes (mock doesn't use router)✅ Fails (404 or error)
Backend contract change❌ Passes (mock returns fantasy data)✅ Fails (real API different)

Maximum Coverage, Minimal Tests

E2E tests are expensive - maximize value per test:

  • Each test covers a complete user journey
  • Combine verification steps that belong to same flow
  • Focus on critical paths and high-risk scenarios
  • Use helper functions to keep tests readable despite complexity

BAD E2E Test Example

test('Should purchase item', async ({ page }) => { // ❌ A.5 - vague title
  await page.goto('/products') // ❌ A.8, A.11 - assumes existing session

  await page.getByText('iPhone 15 Pro').click() // ❌ A.8 - assumes specific product
  await page.locator('#add-to-cart-btn').click() // ❌ A.17 - CSS selector
  await page.goto('/checkout')

  await page.waitForSelector('.form-loaded') // ❌ A.44 - implementation detail
  await page.locator('#email').fill(' [email protected] ') // ❌ A.17, A.55 - CSS + dummy data
  await page.locator('button').last().click() // ❌ A.17, A.40 - positional

  const cartItems = await page.locator('.cart-item').all() // ❌ A.58 - custom loop
  for (const item of cartItems) expect(await item.isVisible()).toBe(true) // ❌ A.58

  await page.goto('https://stripe.com/confirm') // ❌ A.23 - external system
  expect(await page.evaluate(() => localStorage.getItem('orderId'))).toBeTruthy() // ❌ A.14 - implementation
})

GOOD E2E Test Example

test('The user can purchase an item and post-purchase experience is valid', async ({ page }) => {
  // Arrange - Create fresh test data
  const customer = await saveNewCustomer(buildCustomer())
  const product = await saveNewProduct(buildProduct())

  // Act - User journey through semantic helpers
  await navigateToProductsPage(page)
  await selectProduct(page, product)
  await goToCheckout(page)
  await fillCustomerDetails(page, customer)
  await fillPaymentDetails(page, buildCreditCard())

  // Assert - Verify outcomes
  const orderDetails = await submitOrderAndVerifySuccessPage(page)
  await verifyOrderConfirmationEmailSent(customer.email, orderDetails)
  await verifySupplyRequestWasCreated(customer.email, orderDetails)
})

Selector Reference

For detailed selector patterns, page object best practices, and resilience strategies, see:

references/playwright-resilience.md - Comprehensive guide including:

  • Selector priority table (getByRole > getByLabel > getByPlaceholder...)
  • Bad vs Good patterns for forms, buttons, headings, waiting
  • When to use data-testid (error messages, toasts, loading indicators)
  • Page Object best practices
  • Text matching strategies (regex, partial, exact)
  • Quick reference for all element types

Rule Violation Reporting

When reviewing e2e tests, report violations as:

Line X: Violates [RULE_NUMBER] - [Brief explanation]

Example:

Line 8: Violates A.17 - Uses CSS selector '#email', should use getByLabel('Email')
Line 12: Violates A.44 - Uses waitForTimeout, should use auto-retriable assertion
Line 15: Violates A.23 - Navigates to external domain stripe.com

平台分布

windsurf

59.41%
按下载量换算19

Claude Code

30.78%
按下载量换算10

安全审计

暂无安全审计结果可展示。

权限和风险

操作浏览器

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

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills