testing-strategy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Testing Strategy

测试策略

Overview

概述

Analyze the project context and recommend a comprehensive testing strategy. This skill selects appropriate frameworks, defines the testing pyramid, establishes coverage thresholds, and generates test configuration files. The goal is a repeatable, measurable testing foundation that the team can maintain.

Announce at start: "I'm using the testing-strategy skill to define the testing approach."

分析项目上下文并推荐一套完整的测试策略。本技能会选择合适的框架、定义测试金字塔、设置覆盖率阈值，并生成测试配置文件。目标是搭建可重复、可衡量的测试基础，供团队长期维护。

启动时声明： "我将使用testing-strategy技能来定义测试方案。"

Phase 1: Analyze Project

第1阶段：分析项目

Goal: Understand the current stack, existing tests, and CI setup before recommending anything.

目标： 在给出任何推荐前，先了解当前技术栈、已有测试和CI配置情况。

Actions

执行动作

Identify the tech stack (language, framework, runtime)
Survey existing tests (what testing exists already?)
Review CI/CD pipeline (how do tests run?)
Measure current coverage levels
Map external dependencies (services, databases, APIs)

确定技术栈（编程语言、框架、运行时）
调研已有测试（当前已经有哪些测试？）
梳理CI/CD流水线（测试的运行方式是什么？）
衡量当前覆盖率水平
梳理外部依赖（服务、数据库、API）

Discovery Commands

调研命令

bash

undefined

bash

undefined

Identify test files

识别测试文件

find . -name ".test." -o -name ".spec." | head -30

Check for test config

检查测试配置

ls vitest.config.* jest.config.* pytest.ini pyproject.toml .mocharc.* 2>/dev/null

Check current coverage

查看当前覆盖率

cat coverage/coverage-summary.json 2>/dev/null || echo "No coverage report found"

cat coverage/coverage-summary.json 2>/dev/null || echo "未找到覆盖率报告"

Check CI config

检查CI配置

cat .github/workflows/*.yml 2>/dev/null | head -50

undefined

cat .github/workflows/*.yml 2>/dev/null | head -50

undefined

STOP — Do NOT proceed to Phase 2 until:

停止 — 未满足以下条件请勿进入第2阶段：

Tech stack is identified
Existing test infrastructure is mapped
CI pipeline status is known
External dependencies are listed

已确定技术栈
已梳理现有测试基础设施
已明确CI流水线状态
已列出所有外部依赖

Phase 2: Recommend Testing Pyramid

第2阶段：推荐测试金字塔

Goal: Select frameworks and define the pyramid ratios.

目标： 选择测试框架并定义金字塔各层占比。

Framework Selection Table

框架选择表

Stack	Unit	Integration	E2E
Node.js/TS	Vitest	Vitest + Supertest	Playwright
React/Next.js	Vitest + Testing Library	Vitest + MSW	Playwright/Cypress
Python	pytest	pytest + httpx	Playwright
Go	testing + testify	testing + testcontainers	Playwright
Rust	cargo test	cargo test + testcontainers	-
PHP/Laravel	Pest/PHPUnit	Pest + HTTP tests	Playwright/Dusk

技术栈	单元测试	集成测试	E2E测试
Node.js/TS	Vitest	Vitest + Supertest	Playwright
React/Next.js	Vitest + Testing Library	Vitest + MSW	Playwright/Cypress
Python	pytest	pytest + httpx	Playwright
Go	testing + testify	testing + testcontainers	Playwright
Rust	cargo test	cargo test + testcontainers	-
PHP/Laravel	Pest/PHPUnit	Pest + HTTP tests	Playwright/Dusk

Testing Pyramid Ratios

测试金字塔占比

        /\
       /  \     E2E Tests (10%)
      /    \    Critical user journeys only
     /------\
    /        \   Integration Tests (30%)
   /          \  API endpoints, DB queries, service interactions
  /------------\
 /              \ Unit Tests (60%)
/                \ Pure functions, business logic, utilities

        /\
       /  \     E2E测试 (10%)
      /    \    仅覆盖核心用户旅程
     /------\
    /        \   集成测试 (30%)
   /          \  API端点、数据库查询、服务交互
  /------------\
 /              \ 单元测试 (60%)
/                \ 纯函数、业务逻辑、工具方法

What to Test at Each Level

各层测试范围

Level	Test These	Do NOT Test These
Unit (60%)	Pure functions, business logic, data transformations, validations, state management	Framework internals, third-party libraries
Integration (30%)	API endpoints, database queries, service-to-service calls, auth flows	Individual functions in isolation
E2E (10%)	Critical user journeys (signup, purchase), cross-browser, accessibility	Edge cases (handle at unit level)

层级	测试内容	不测试内容
单元测试 (60%)	纯函数、业务逻辑、数据转换、校验、状态管理	框架内部实现、第三方库
集成测试 (30%)	API端点、数据库查询、服务间调用、鉴权流程	独立运行的单个函数
E2E测试 (10%)	核心用户旅程（注册、支付）、跨浏览器兼容性、可访问性	边界场景（放在单元测试层覆盖）

STOP — Do NOT proceed to Phase 3 until:

停止 — 未满足以下条件请勿进入第3阶段：

Framework selection matches the tech stack
Pyramid ratios are defined
Testing scope at each level is documented

选择的框架匹配技术栈
已定义金字塔各层占比
已记录各层级的测试范围

Phase 3: Define Coverage Thresholds

第3阶段：定义覆盖率阈值

Goal: Set realistic, enforceable coverage targets.

目标： 设置符合实际、可强制执行的覆盖率目标。

Coverage Threshold Table

覆盖率阈值表

Category	Minimum	Target	Notes
Overall	70%	85%	Lines covered
Critical paths	90%	95%	Auth, payments, data access
New code (PRs)	80%	90%	Enforced in CI
Utilities	95%	100%	Pure functions are easy to test

类别	最低要求	目标值	说明
整体	70%	85%	代码行覆盖率
核心路径	90%	95%	鉴权、支付、数据访问
新代码（PR提交）	80%	90%	在CI中强制校验
工具方法	95%	100%	纯函数易测试

Threshold Selection Decision Table

阈值选择决策表

Project Maturity	Overall Minimum	New Code Minimum	Rationale
Greenfield	80%	90%	Start high, maintain standard
Active (good coverage)	70%	85%	Maintain and improve
Legacy (low coverage)	50%	80%	Raise floor gradually
Prototype/MVP	60%	70%	Cover critical paths, accept gaps

项目成熟度	整体最低覆盖率	新代码最低覆盖率	逻辑
全新项目	80%	90%	高起点起步，保持标准
活跃迭代（覆盖率良好）	70%	85%	保持并逐步提升
遗留项目（覆盖率低）	50%	80%	逐步提升最低要求
原型/MVP	60%	70%	覆盖核心路径，允许存在缺口

STOP — Do NOT proceed to Phase 4 until:

停止 — 未满足以下条件请勿进入第4阶段：

Coverage thresholds are realistic for the project maturity
Critical path coverage targets are defined
CI enforcement strategy is decided

覆盖率阈值符合项目成熟度的实际情况
已定义核心路径的覆盖率目标
已确定CI强制校验策略

Phase 4: Generate Configuration

第4阶段：生成配置文件

Goal: Produce working test configuration files and CI integration.

目标： 输出可运行的测试配置文件和CI集成配置。

Actions

执行动作

Generate test runner config (

vitest.config.ts

jest.config.js

pytest.ini

)

Configure coverage with thresholds
Add test commands to CI workflow
Set up test environment (
```
.env.test
```
, test databases)

生成测试运行器配置（

vitest.config.ts

、

jest.config.js

、

pytest.ini

）

配置带阈值的覆盖率规则
在CI工作流中添加测试命令
搭建测试环境（
```
.env.test
```
、测试数据库）

Example: Vitest Config

示例：Vitest配置

typescript

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      thresholds: {
        lines: 80,
        functions: 80,
        branches: 80,
        statements: 80,
      },
    },
    include: ['src/**/*.test.{ts,tsx}'],
  },
});

typescript

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'jsdom',
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      thresholds: {
        lines: 80,
        functions: 80,
        branches: 80,
        statements: 80,
      },
    },
    include: ['src/**/*.test.{ts,tsx}'],
  },
});

STOP — Do NOT proceed to Phase 5 until:

停止 — 未满足以下条件请勿进入第5阶段：

Config files are syntactically valid
Coverage thresholds match Phase 3 decisions
CI integration commands are defined

配置文件语法正确
覆盖率阈值和第3阶段的决策一致
已定义CI集成命令

Phase 5: Create Test Templates

第5阶段：创建测试模板

Goal: Provide example test files demonstrating project conventions.

目标： 提供示例测试文件，展示项目的测试规范。

Actions

执行动作

Create a unit test example with Arrange-Act-Assert
Create an integration test with setup/teardown
Create mock/stub patterns for external dependencies
Create test data factories/fixtures
Create a snapshot test example (when appropriate)

创建遵循Arrange-Act-Assert规范的单元测试示例
创建包含setup/teardown的集成测试示例
提供外部依赖的mock/stub模式示例
创建测试数据工厂/夹具示例
（适用时）创建快照测试示例

STOP — Verification Gate before claiming complete:

停止 — 标记完成前的验证关卡：

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-Pattern	Why It Is Wrong	Correct Approach
Testing implementation details	Breaks on every refactor, provides false confidence	Test behavior and outcomes
Excessive mocking	Tests nothing real, mocks mask real failures	Mock at boundaries only
Brittle CSS selectors in E2E	Break with styling changes	Use data-testid or accessible roles
Test interdependence	Ordering failures, flaky in CI	Each test must run independently
Slow tests blocking CI	Developers skip running tests	Parallelize, use test databases, mock external APIs
Snapshot overuse	Snapshots approved without reading, stale baselines	Use for stable output only
No coverage enforcement in CI	Coverage degrades over time	Enforce thresholds in CI pipeline
Same coverage target everywhere	Utilities and critical paths differ	Use per-category thresholds

反模式	错误原因	正确做法
测试实现细节	每次重构都会导致测试失败，提供虚假的信心	测试行为和结果
过度mock	没有测试真实逻辑，mock会掩盖真实故障	仅在边界层做mock
E2E测试中使用脆弱的CSS选择器	样式修改就会导致测试失败	使用data-testid或可访问性角色
测试相互依赖	会出现顺序相关的失败，在CI中表现不稳定	每个测试都要能独立运行
测试运行慢阻塞CI	开发者会跳过运行测试	并行执行、使用测试数据库、mock外部API
滥用快照	快照不经审核就被批准，基线过时	仅用于稳定的输出场景
CI中没有强制校验覆盖率	覆盖率会随时间逐步降低	在CI流水线中强制校验阈值
所有模块使用相同的覆盖率目标	工具方法和核心路径的要求存在差异	按分类设置不同阈值

Decision Table: Mock Strategy

决策表：Mock策略

Dependency Type	Mock Strategy	Example
External API	MSW / nock / responses	Third-party payment API
Database	Test database or in-memory	PostgreSQL test container
File system	Virtual FS or temp directory	File upload processing
Time/Date	Fake timers	Expiration logic
Environment vars	Override in test setup	Feature flags
Random/UUID	Seed or stub	ID generation

依赖类型	Mock策略	示例
外部API	MSW / nock / responses	第三方支付API
数据库	测试数据库或内存数据库	PostgreSQL测试容器
文件系统	虚拟FS或临时目录	文件上传处理
时间/日期	假计时器	过期逻辑
环境变量	在测试启动时覆盖	功能开关
随机数/UUID	固定种子或stub	ID生成

Integration Points

集成点

Skill	Relationship
`test-driven-development`	Strategy defines frameworks; TDD defines the cycle
`acceptance-testing`	Strategy includes acceptance test infrastructure
`code-review`	Review checks that tests follow the defined strategy
`senior-frontend`	Frontend testing uses strategy-selected frameworks
`senior-backend`	Backend testing uses strategy-selected frameworks
`performance-optimization`	Load tests are part of the overall testing strategy
`webapp-testing`	Playwright E2E tests follow strategy pyramid

技能	关联关系
`test-driven-development`	测试策略定义框架，TDD定义开发周期
`acceptance-testing`	测试策略包含验收测试基础设施
`code-review`	代码评审检查测试是否符合定义的策略
`senior-frontend`	前端测试使用策略选定的框架
`senior-backend`	后端测试使用策略选定的框架
`performance-optimization`	压力测试属于整体测试策略的一部分
`webapp-testing`	Playwright E2E测试遵循策略的金字塔结构

Key Principles

核心原则

Test behavior, not implementation — what it does, not how
Fast feedback — unit tests should run in seconds
Deterministic — no flaky tests, no time-dependent logic
Readable — tests are documentation; make them clear
Maintainable — tests should help refactoring, not block it

测试行为，而非实现 — 关注做什么，而非怎么做
快速反馈 — 单元测试应当在数秒内运行完成
确定性 — 不存在不稳定的测试，不存在时间依赖逻辑
可读性 — 测试就是文档，要清晰易懂
可维护性 — 测试应当助力重构，而非阻碍重构

Skill Type

技能类型

FLEXIBLE — Adapt framework selection and coverage thresholds to the project context. The five-phase process and testing pyramid structure are strongly recommended but can be scaled to project size.

灵活适配型 — 可以根据项目上下文调整框架选择和覆盖率阈值。强烈建议遵循五阶段流程和测试金字塔结构，但可根据项目规模做适配。