Token导航 LogoToken导航TokenDH.com
研究检索操作浏览器github未标认证来源可访问clear审计未展示

testing-e2e测试端到端

Agent Skill

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

总安装

96

周安装

4

GitHub Stars

公开资料未说明

下载量

32
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 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"

简介

专注于端到端(E2E)测试的支持。

  • 协助构建完整的用户流程测试用例。testing-e2e 属于研究检索类 Skill,可作为该场景下的辅助能力补充。
  • 可用于验证系统整体功能和交互逻辑。
  • 需配置合适的测试环境和模拟数据。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • 执行前应评估对生产系统的影响风险。

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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

windsurf

59.41%
按下载量换算19

Claude Code

30.78%
按下载量换算10

安全审计

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

权限和风险

操作浏览器

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

安装前确认

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

来源信息

继续浏览同类 Skills