Back to Details

testing-strategies

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Testing Strategies

测试策略

Build comprehensive, effective test suites by strategically selecting and implementing the right testing approaches across unit, integration, E2E, and contract testing levels.
通过针对性选择和实施单元测试、集成测试、E2E测试及契约测试各层级的合适测试方法，构建全面且高效的测试套件。

Purpose

目标

This skill provides strategic frameworks for:
  • Test Type Selection: Determine when to use unit vs. integration vs. E2E vs. contract testing
  • Test Pyramid Balancing: Optimize test distribution for fast feedback and reliable coverage
  • Multi-Language Implementation: Apply consistent testing patterns across TypeScript, Python, Go, and Rust
  • Test Data Management: Choose appropriate strategies (fixtures, factories, property-based testing)
  • CI/CD Integration: Integrate tests into automated pipelines with optimal execution patterns
Testing is foundational to reliable software. With microservices architectures and continuous delivery becoming standard in 2025, strategic testing across multiple levels is more critical than ever.
本技能提供以下方面的战略框架：
  • 测试类型选择：确定何时使用单元测试、集成测试、E2E测试或契约测试
  • 测试金字塔平衡：优化测试分布，实现快速反馈与可靠覆盖
  • 多语言实施：在TypeScript、Python、Go和Rust中应用一致的测试模式
  • 测试数据管理：选择合适的策略（固定测试数据、生成式测试数据、基于属性的测试）
  • CI/CD集成：将测试以最优执行模式集成到自动化流水线中
测试是可靠软件的基础。随着微服务架构和持续交付在2025年成为标准，跨多层级的战略性测试比以往任何时候都更为关键。

When to Use This Skill

适用场景

Invoke this skill when:
  • Building a new feature that requires test coverage
  • Designing a testing strategy for a new project
  • Refactoring existing tests to improve speed or reliability
  • Setting up CI/CD pipelines with testing stages
  • Choosing between unit, integration, or E2E testing approaches
  • Implementing contract testing for microservices
  • Managing test data with fixtures, factories, or property-based testing
在以下场景中调用本技能：
  • 构建需要测试覆盖的新功能
  • 为新项目设计测试策略
  • 重构现有测试以提升速度或可靠性
  • 搭建包含测试阶段的CI/CD流水线
  • 在单元、集成或E2E测试方法间做选择
  • 为微服务实施契约测试
  • 使用固定测试数据、生成式测试数据或基于属性的测试管理测试数据

The Testing Pyramid Framework

测试金字塔框架

Core Concept

核心概念

The testing pyramid guides test distribution for optimal speed and confidence:
         /\
        /  \  E2E Tests (10%)
       /----\  - Slow but comprehensive
      /      \  - Full stack validation
     /--------\
    /          \  Integration Tests (20-30%)
   /            \  - Moderate speed
  /--------------\  - Component interactions
 /                \
/------------------\  Unit Tests (60-70%)
                      - Fast feedback
                      - Isolated units
Key Principle: More unit tests (fast, isolated), fewer E2E tests (slow, comprehensive). Integration tests bridge the gap.
测试金字塔指导测试分布，以实现最优的速度与可信度：
         /\
        /  \  E2E Tests (10%)
       /----\  - 速度慢但覆盖全面
      /      \  - 全栈验证
     /--------\
    /          \  Integration Tests (20-30%)
   /            \  - 速度中等
  /--------------\  - 组件交互验证
 /                \
/------------------\  Unit Tests (60-70%)
                      - 快速反馈
                      - 隔离单元验证
核心原则：更多单元测试（快速、隔离），更少E2E测试（缓慢、全面）。集成测试填补两者之间的空白。

Modern Adaptations (2025)

2025年现代适配方案

Microservices Adjustment:
  • Add contract testing layer between unit and integration
  • Increase integration/contract tests to 30% (validate service boundaries)
  • Reduce E2E tests to critical user journeys only
Cloud-Native Patterns:
  • Use containers for integration tests (ephemeral databases, test services)
  • Parallel execution for fast CI/CD feedback
  • Risk-based test prioritization (focus on high-impact areas)
For detailed pyramid guidance, see 
references/testing-pyramid.md
.
微服务调整：
  • 在单元测试与集成测试之间添加契约测试层
  • 将集成/契约测试占比提升至30%（验证服务边界）
  • 将E2E测试仅保留在关键用户流程中
云原生模式：
  • 使用容器进行集成测试（临时数据库、测试服务）
  • 并行执行以实现CI/CD快速反馈
  • 基于风险的测试优先级划分（聚焦高影响区域）
如需详细的金字塔指导，请参阅
references/testing-pyramid.md
。

Universal Testing Decision Tree

通用测试决策树

Which Test Type Should I Use?

应选择哪种测试类型？

START: Need to test [feature]

Q1: Does this involve multiple systems/services?
  ├─ YES → Q2
  └─ NO  → Q3

Q2: Is this a critical user-facing workflow?
  ├─ YES → E2E Test (complete user journey)
  └─ NO  → Integration or Contract Test

Q3: Does this interact with external dependencies (DB, API, filesystem)?
  ├─ YES → Integration Test (real DB, mocked API)
  └─ NO  → Q4

Q4: Is this pure business logic or a pure function?
  ├─ YES → Unit Test (fast, isolated)
  └─ NO  → Component or Integration Test
开始：需要测试[功能]

问题1：是否涉及多个系统/服务？
  ├─ 是 → 问题2
  └─ 否 → 问题3

问题2：是否为关键用户面向的工作流？
  ├─ 是 → E2E测试（完整用户流程）
  └─ 否 → 集成测试或契约测试

问题3：是否与外部依赖（数据库、API、文件系统）交互？
  ├─ 是 → 集成测试（真实数据库、模拟API）
  └─ 否 → 问题4

问题4：是否为纯业务逻辑或纯函数？
  ├─ 是 → 单元测试（快速、隔离）
  └─ 否 → 组件测试或集成测试

Test Type Selection Examples

测试类型选择示例

FeatureTest TypeRationale
calculateTotal(items)
UnitPure function, no dependencies
POST /api/users
endpoint		IntegrationTests API + database interaction
User registration flow (form → API → redirect)E2ECritical user journey, full stack
Microservice A → B communicationContractService interface validation
formatCurrency(amount, locale)
Unit + PropertyPure logic, many edge cases
Form validation logicUnitIsolated business rules
File upload to S3IntegrationExternal service interaction
For comprehensive decision frameworks, see 
references/decision-tree.md
.
功能测试类型理由
calculateTotal(items)
单元测试纯函数，无依赖
POST /api/users
接口		集成测试测试API与数据库的交互
用户注册流程（表单→API→重定向）E2E测试关键用户流程，全栈验证
微服务A→B通信契约测试服务接口验证
formatCurrency(amount, locale)
单元测试+基于属性的测试纯逻辑，存在多种边缘情况
表单验证逻辑单元测试隔离的业务规则验证
上传文件至S3集成测试与外部服务交互
如需全面的决策框架，请参阅
references/decision-tree.md
。

Testing Levels in Detail

各层级测试详情

Unit Testing (Foundation - 60-70%)

单元测试（基础层 - 60-70%）

Purpose: Validate small, isolated units of code (functions, methods, components)
Characteristics:
  • Fast (milliseconds per test)
  • Isolated (no external dependencies)
  • Deterministic (same input = same output)
  • Broad coverage (many tests, small scope each)
When to Use:
  • Pure functions (input → output)
  • Business logic and algorithms
  • Utility functions
  • Component rendering (without integration)
  • Validation logic
Recommended Tools:
  • TypeScript/JavaScript: Vitest (primary, 10x faster than Jest), Jest (legacy)
  • Python: pytest (industry standard)
  • Go: testing package (stdlib) + testify (assertions)
  • Rust: cargo test (stdlib)
For detailed patterns, see 
references/unit-testing-patterns.md
.
目标：验证小型、隔离的代码单元（函数、方法、组件）
特点:
  • 快速（每个测试仅需数毫秒）
  • 隔离（无外部依赖）
  • 确定性（相同输入=相同输出）
  • 覆盖范围广（测试数量多，单个测试范围小）
适用场景:
  • 纯函数（输入→输出）
  • 业务逻辑与算法
  • 工具函数
  • 组件渲染（无集成）
  • 验证逻辑
推荐工具:
  • TypeScript/JavaScript: Vitest（首选，比Jest快10倍），Jest（旧版）
  • Python: pytest（行业标准）
  • Go: testing包（标准库）+ testify（断言库）
  • Rust: cargo test（标准库）
如需详细模式，请参阅
references/unit-testing-patterns.md
。

Integration Testing (Middle Layer - 20-30%)

集成测试（中间层 - 20-30%）

Purpose: Validate interactions between components, modules, or services
Characteristics:
  • Moderate speed (seconds per test)
  • Partial integration (real database, mocked external APIs)
  • Focused scope (test component boundaries)
  • API and database validation
When to Use:
  • API endpoints (request → response)
  • Database operations (CRUD, queries)
  • Service-to-service communication
  • Event handlers and message processing
  • File I/O operations
Recommended Tools:
  • TypeScript/JavaScript: Vitest + MSW (API mocking), Supertest (HTTP testing)
  • Python: pytest + pytest-httpserver, pytest-postgresql
  • Go: testing + httptest, testcontainers
  • Rust: cargo test + mockito, testcontainers
For detailed patterns, see 
references/integration-testing-patterns.md
.
目标：验证组件、模块或服务之间的交互
特点:
  • 速度中等（每个测试需数秒）
  • 部分集成（真实数据库、模拟外部API）
  • 聚焦范围（测试组件边界）
  • API与数据库验证
适用场景:
  • API接口（请求→响应）
  • 数据库操作（CRUD、查询）
  • 服务间通信
  • 事件处理器与消息处理
  • 文件I/O操作
推荐工具:
  • TypeScript/JavaScript: Vitest + MSW（API模拟），Supertest（HTTP测试）
  • Python: pytest + pytest-httpserver，pytest-postgresql
  • Go: testing + httptest，testcontainers
  • Rust: cargo test + mockito，testcontainers
如需详细模式，请参阅
references/integration-testing-patterns.md
。

End-to-End Testing (Top Layer - 10%)

E2E测试（顶层 - 10%）

Purpose: Validate complete user workflows across the entire application stack
Characteristics:
  • Slow (minutes per test suite)
  • Full integration (real browser, services, database)
  • Wide scope (user journeys from start to finish)
  • Prone to flakiness (requires careful design)
When to Use:
  • Critical user journeys (login, checkout, payment)
  • Cross-browser compatibility validation
  • Real-world scenarios not covered by integration tests
  • Regression prevention for core features
Best Practices:
  • Limit E2E tests to high-value scenarios (not every edge case)
  • Use stable selectors (data-testid, not CSS classes)
  • Implement retry logic for network flakiness
  • Run tests in parallel for speed
Recommended Tools:
  • All Languages: Playwright (cross-browser, fast, Microsoft-backed)
For detailed patterns, see 
references/e2e-testing-patterns.md
.
目标：验证整个应用栈中的完整用户工作流
特点:
  • 缓慢（每个测试套件需数分钟）
  • 全集成（真实浏览器、服务、数据库）
  • 范围广（从开始到结束的用户流程）
  • 易出现不稳定情况（需精心设计）
适用场景:
  • 关键用户流程（登录、结账、支付）
  • 跨浏览器兼容性验证
  • 集成测试未覆盖的真实场景
  • 核心功能的回归预防
最佳实践:
  • 将E2E测试限制在高价值场景（而非每个边缘情况）
  • 使用稳定选择器（data-testid，而非CSS类）
  • 为网络不稳定情况实现重试逻辑
  • 并行执行测试以提升速度
推荐工具:
  • 所有语言: Playwright（跨浏览器、快速、微软支持）
如需详细模式，请参阅
references/e2e-testing-patterns.md
。

Contract Testing (Microservices)

契约测试（微服务）

Purpose: Validate service interfaces and API contracts without full integration
When to Use:
  • Microservices architecture
  • Service-to-service communication
  • API contract validation
  • Reducing E2E testing overhead
Recommended Tool: Pact (pact.io) - supports TypeScript, Python, Go, Rust
For detailed patterns, see 
references/contract-testing.md
.
目标：无需全集成即可验证服务接口与API契约
适用场景:
  • 微服务架构
  • 服务间通信
  • API契约验证
  • 减少E2E测试开销
推荐工具: Pact（pact.io）- 支持TypeScript、Python、Go、Rust
如需详细模式，请参阅
references/contract-testing.md
。

Test Data Management Strategies

测试数据管理策略

When to Use Each Approach

各方法适用场景

Fixtures (Static Data):
  • Pros: Deterministic, easy to debug
  • Cons: Can become stale, doesn't test variety
  • Use When: Testing known scenarios, regression tests
Factories (Generated Data):
  • Pros: Flexible, generates variety
  • Cons: Less deterministic, harder to debug
  • Use When: Need diverse test data, testing edge cases
Property-Based Testing (Random Data):
  • Pros: Finds edge cases not anticipated
  • Cons: Can be slow, failures harder to reproduce
  • Use When: Complex algorithms, parsers, validators
Recommended Combination:
  • Unit Tests: Fixtures (known inputs) + Property-Based (edge cases)
  • Integration Tests: Factories (flexible data) + Database seeding
  • E2E Tests: Fixtures (reproducible scenarios)
Property-Based Testing Tools:
  • TypeScript/JavaScript: fast-check
  • Python: hypothesis (best-in-class)
  • Go: gopter
  • Rust: proptest (primary)
For detailed strategies, see 
references/test-data-strategies.md
.
固定测试数据（静态数据）:
  • 优点：确定性强，易于调试
  • 缺点：可能过时，无法测试多样性
  • 适用场景：测试已知场景、回归测试
生成式测试数据（动态生成）:
  • 优点：灵活，可生成多样数据
  • 缺点：确定性较低，调试难度大
  • 适用场景：需要多样化测试数据、测试边缘情况
基于属性的测试（随机数据）:
  • 优点：能发现未预料到的边缘情况
  • 缺点：速度较慢，故障重现难度大
  • 适用场景：复杂算法、解析器、验证器
推荐组合:
  • 单元测试: 固定测试数据（已知输入）+ 基于属性的测试（边缘情况）
  • 集成测试: 生成式测试数据（灵活数据）+ 数据库初始化
  • E2E测试: 固定测试数据（可重现场景）
基于属性的测试工具:
  • TypeScript/JavaScript: fast-check
  • Python: hypothesis（行业领先）
  • Go: gopter
  • Rust: proptest（首选）
如需详细策略，请参阅
references/test-data-strategies.md
。

Mocking Decision Matrix

模拟决策矩阵

When to Mock vs. Use Real Dependencies

何时模拟 vs 使用真实依赖

DependencyUnit TestIntegration TestE2E Test
DatabaseMock (in-memory)Real (test DB, Docker)Real (staging DB)
External APIMock (MSW, nock)Mock (MSW, VCR)Real (or staging)
FilesystemMock (in-memory FS)Real (temp directory)Real
Time/DateMock (freezeTime)Mock (if deterministic)Real (usually)
Environment VariablesMock (setEnv)Mock (test config)Real (test env)
Internal ServicesMock (stub)Real (or container)Real
Guiding Principles:
  1. Unit Tests: Mock everything external
  2. Integration Tests: Use real database (ephemeral), mock external APIs
  3. E2E Tests: Use real everything (or staging equivalents)
  4. Contract Tests: Mock nothing (test real interfaces)
For detailed mocking patterns, see 
references/mocking-strategies.md
.
依赖单元测试集成测试E2E测试
数据库模拟（内存数据库）真实（测试数据库、Docker）真实（预发布环境数据库）
外部API模拟（MSW、nock）模拟（MSW、VCR）真实（或预发布环境）
文件系统模拟（内存文件系统）真实（临时目录）真实
时间/日期模拟（冻结时间）模拟（如需确定性）真实（通常）
环境变量模拟（设置Env）模拟（测试配置）真实（测试环境）
内部服务模拟（存根）真实（或容器）真实
指导原则:
  1. 单元测试: 模拟所有外部依赖
  2. 集成测试: 使用真实数据库（临时），仅模拟外部API
  3. E2E测试: 使用所有真实依赖（或预发布环境等价物）
  4. 契约测试: 不模拟任何依赖（测试真实接口）
如需详细模拟模式，请参阅
references/mocking-strategies.md
。

Language-Specific Quick Starts

语言快速入门

TypeScript/JavaScript

TypeScript/JavaScript

Unit Testing with Vitest:
typescript
import { describe, test, expect } from 'vitest'

test('calculates total with tax', () => {
  const items = [{ price: 10, quantity: 2 }]
  expect(calculateTotal(items, 0.1)).toBe(22)
})
Integration Testing with MSW:
typescript
import { setupServer } from 'msw/node'
import { http, HttpResponse } from 'msw'

const server = setupServer(
  http.get('/api/user/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Test User' })
  })
)
E2E Testing with Playwright:
typescript
import { test, expect } from '@playwright/test'

test('user can checkout', async ({ page }) => {
  await page.goto('https://example.com')
  await page.getByRole('button', { name: 'Add to Cart' }).click()
  await expect(page.getByText('1 item in cart')).toBeVisible()
})
See 
examples/typescript/
for complete working examples.
使用Vitest进行单元测试:
typescript
import { describe, test, expect } from 'vitest'

test('calculates total with tax', () => {
  const items = [{ price: 10, quantity: 2 }]
  expect(calculateTotal(items, 0.1)).toBe(22)
})
使用MSW进行集成测试:
typescript
import { setupServer } from 'msw/node'
import { http, HttpResponse } from 'msw'

const server = setupServer(
  http.get('/api/user/:id', ({ params }) => {
    return HttpResponse.json({ id: params.id, name: 'Test User' })
  })
)
使用Playwright进行E2E测试:
typescript
import { test, expect } from '@playwright/test'

test('user can checkout', async ({ page }) => {
  await page.goto('https://example.com')
  await page.getByRole('button', { name: 'Add to Cart' }).click()
  await expect(page.getByText('1 item in cart')).toBeVisible()
})
完整可运行示例请查看
examples/typescript/
。

Python

Python

Unit Testing with pytest:
python
def test_calculate_total_with_tax():
    items = [{"price": 10, "quantity": 2}]
    assert calculate_total(items, tax_rate=0.1) == 22
Property-Based Testing with hypothesis:
python
from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_reverse_reverse_is_identity(lst):
    assert reverse(reverse(lst)) == lst
See 
examples/python/
for complete working examples.
使用pytest进行单元测试:
python
def test_calculate_total_with_tax():
    items = [{"price": 10, "quantity": 2}]
    assert calculate_total(items, tax_rate=0.1) == 22
使用hypothesis进行基于属性的测试:
python
from hypothesis import given, strategies as st

@given(st.lists(st.integers()))
def test_reverse_reverse_is_identity(lst):
    assert reverse(reverse(lst)) == lst
完整可运行示例请查看
examples/python/
。

Go and Rust

Go和Rust

See 
examples/go/
and 
examples/rust/
for complete working examples in these languages.
完整可运行示例请查看
examples/go/
和
examples/rust/
。

Coverage and Quality Metrics

覆盖率与质量指标

Meaningful Coverage Targets

有意义的覆盖率目标

Recommended Targets:
  • Critical Business Logic: 90%+ coverage
  • API Endpoints: 80%+ coverage
  • Utility Functions: 70%+ coverage
  • UI Components: 60%+ coverage (focus on logic, not markup)
  • Overall Project: 70-80% coverage
Anti-Pattern: Aiming for 100% coverage leads to testing trivial code and false confidence.
Coverage Tools:
  • TypeScript/JavaScript: Vitest coverage (c8/istanbul)
  • Python: pytest-cov
  • Go: go test -cover
  • Rust: cargo-tarpaulin
推荐目标:
  • 关键业务逻辑: 90%+ 覆盖率
  • API接口: 80%+ 覆盖率
  • 工具函数: 70%+ 覆盖率
  • UI组件: 60%+ 覆盖率（聚焦逻辑，而非标记）
  • 整体项目: 70-80% 覆盖率
反模式: 追求100%覆盖率会导致测试无关代码，产生虚假的可信度。
覆盖率工具:
  • TypeScript/JavaScript: Vitest coverage（c8/istanbul）
  • Python: pytest-cov
  • Go: go test -cover
  • Rust: cargo-tarpaulin

Mutation Testing (Validate Test Quality)

变异测试（验证测试质量）

Mutation testing introduces bugs and verifies tests catch them.
Tools:
  • TypeScript/JavaScript: Stryker Mutator
  • Python: mutmut
  • Go: go-mutesting
  • Rust: cargo-mutants
For detailed coverage strategies, see 
references/coverage-strategies.md
.
变异测试会引入错误并验证测试是否能捕获这些错误。
工具:
  • TypeScript/JavaScript: Stryker Mutator
  • Python: mutmut
  • Go: go-mutesting
  • Rust: cargo-mutants
如需详细的覆盖率策略，请参阅
references/coverage-strategies.md
。

CI/CD Integration Patterns

CI/CD集成模式

Fast Feedback Loop Strategy

快速反馈循环策略

Stage 1: Pre-Commit (< 30 seconds)
  • Lint and format checks
  • Unit tests (critical paths only)
Stage 2: On Commit (< 2 minutes)
  • All unit tests
  • Static analysis
Stage 3: Pull Request (< 5 minutes)
  • Integration tests
  • Coverage reporting
Stage 4: Pre-Merge (< 10 minutes)
  • E2E tests (critical paths)
  • Cross-browser testing
阶段1: 提交前（<30秒）
  • 代码检查与格式校验
  • 单元测试（仅关键路径）
阶段2: 提交后（<2分钟）
  • 所有单元测试
  • 静态分析
阶段3: 拉取请求（<5分钟）
  • 集成测试
  • 覆盖率报告
阶段4: 合并前（<10分钟）
  • E2E测试（关键路径）
  • 跨浏览器测试

Parallel Execution

并行执行

Speed Up Test Runs:
  • Vitest: 
    vitest --threads
  • Playwright: 
    playwright test --workers=4
  • pytest: 
    pytest -n auto
    (requires pytest-xdist)
  • Go: 
    go test -parallel 4
加速测试运行:
  • Vitest: 
    vitest --threads
  • Playwright: 
    playwright test --workers=4
  • pytest: 
    pytest -n auto
    （需要pytest-xdist）
  • Go: 
    go test -parallel 4

Common Anti-Patterns to Avoid

需避免的常见反模式

The Ice Cream Cone (Inverted Pyramid)

甜筒模式（倒置金字塔）

Problem: Too many E2E tests, too few unit tests Result: Slow test suites, flaky tests, long feedback loops Solution: Rebalance toward more unit tests, fewer E2E tests
问题: E2E测试过多，单元测试过少 结果: 测试套件缓慢、不稳定，反馈周期长 解决方案: 重新平衡测试分布，增加单元测试，减少E2E测试

Testing Implementation Details

测试实现细节

Problem: Tests coupled to internal structure, not behavior Solution: Test behavior (inputs → outputs), not implementation
问题: 测试与内部结构耦合，而非行为 解决方案: 测试行为（输入→输出），而非实现细节

Over-Mocking in Integration Tests

集成测试过度模拟

Problem: Mocking everything defeats purpose of integration tests Solution: Use real databases (ephemeral), mock only external APIs
问题: 模拟所有依赖违背了集成测试的目的 解决方案: 使用真实数据库（临时），仅模拟外部API

Flaky E2E Tests

不稳定的E2E测试

Problem: Tests fail intermittently due to timing issues Solutions:
  • Use auto-wait features (Playwright has built-in auto-wait)
  • Avoid hardcoded waits (
    sleep(1000)
    )
  • Use stable selectors (data-testid)
  • Implement retry logic for network requests
问题: 因时序问题导致测试间歇性失败 解决方案:
  • 使用自动等待功能（Playwright内置自动等待）
  • 避免硬编码等待（
    sleep(1000)
    ）
  • 使用稳定选择器（data-testid）
  • 为网络请求实现重试逻辑

Integration with Other Skills

与其他技能的集成

For form testing: See 
building-forms
skill for form-specific validation and submission testing patterns.
For API testing: See 
api-patterns
skill for REST/GraphQL endpoint testing and contract validation.
For CI/CD pipelines: See 
building-ci-pipelines
skill for test automation, parallel execution, and coverage reporting.
For data visualization testing: See 
visualizing-data
skill for snapshot testing chart configurations and visual regression testing.
表单测试: 请参阅
building-forms
技能，获取表单特定的验证与提交测试模式。
API测试: 请参阅
api-patterns
技能，获取REST/GraphQL接口测试与契约验证的内容。
CI/CD流水线: 请参阅
building-ci-pipelines
技能，获取测试自动化、并行执行与覆盖率报告的内容。
数据可视化测试: 请参阅
visualizing-data
技能，获取快照测试图表配置与视觉回归测试的内容。

Reference Documentation

参考文档

For deeper exploration of specific topics:
  • references/testing-pyramid.md
     - Detailed testing pyramid framework and balancing strategies
  • references/decision-tree.md
     - Comprehensive decision frameworks for test type selection
  • references/unit-testing-patterns.md
     - Unit testing patterns across languages
  • references/integration-testing-patterns.md
     - Integration testing with databases, APIs, and containers
  • references/e2e-testing-patterns.md
     - E2E testing best practices and Playwright patterns
  • references/contract-testing.md
     - Consumer-driven contract testing with Pact
  • references/test-data-strategies.md
     - Fixtures, factories, and property-based testing
  • references/mocking-strategies.md
     - When and how to mock dependencies
  • references/coverage-strategies.md
     - Meaningful coverage metrics and mutation testing
如需深入探索特定主题：
  • references/testing-pyramid.md
     - 详细的测试金字塔框架与平衡策略
  • references/decision-tree.md
     - 全面的测试类型选择决策框架
  • references/unit-testing-patterns.md
     - 跨语言的单元测试模式
  • references/integration-testing-patterns.md
     - 涉及数据库、API与容器的集成测试
  • references/e2e-testing-patterns.md
     - E2E测试最佳实践与Playwright模式
  • references/contract-testing.md
     - 基于Pact的消费者驱动契约测试
  • references/test-data-strategies.md
     - 固定测试数据、生成式测试数据与基于属性的测试
  • references/mocking-strategies.md
     - 何时及如何模拟依赖
  • references/coverage-strategies.md
     - 有意义的覆盖率指标与变异测试

Working Examples

可运行示例

Complete, runnable code examples are available in the 
examples/
directory:
  • examples/typescript/
     - Vitest unit/integration, Playwright E2E, MSW mocking, fast-check property tests
  • examples/python/
     - pytest unit/integration, fixtures, Playwright E2E, hypothesis property tests
  • examples/go/
     - stdlib testing, testify assertions, httptest integration
  • examples/rust/
     - cargo test unit tests, proptest property tests, integration patterns
All examples include dependencies, usage instructions, and error handling.
完整的可运行代码示例位于
examples/
目录：
  • examples/typescript/
     - Vitest单元/集成测试、Playwright E2E测试、MSW模拟、fast-check基于属性的测试
  • examples/python/
     - pytest单元/集成测试、固定测试数据、Playwright E2E测试、hypothesis基于属性的测试
  • examples/go/
     - 标准库测试、testify断言、httptest集成测试
  • examples/rust/
     - cargo test单元测试、proptest基于属性的测试、集成测试模式
所有示例均包含依赖、使用说明与错误处理。