Back to Details

testing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Testing Strategy — The Test Trophy

测试策略 — Test Trophy模型

Overview

概述

The Test Trophy (Kent C. Dodds) is a modern testing strategy that prioritizes integration tests over unit tests, reflecting how today's tooling has shifted the cost/confidence tradeoffs of each test category.
"Write tests. Not too many. Mostly integration." — Kent C. Dodds
Test Trophy（由Kent C. Dodds提出）是一种现代测试策略，它将集成测试置于比单元测试更优先的位置，反映了当前工具链如何改变了各类测试的成本与可信度权衡关系。
"编写测试，但不要写太多。主要写集成测试。" — Kent C. Dodds

The Test Trophy

Test Trophy模型

                  ┌───────┐
                  │  E2E  │  Few, high-confidence, slow, expensive
                 ─┴───────┴─
               ┌─────────────┐
               │ Integration  │  Most tests here — best ROI
              ─┴─────────────┴─
            ┌───────────────────┐
            │       Unit        │  Isolated logic, fast, cheap
           ─┴───────────────────┴─
         ┌───────────────────────────┐
         │     Static Analysis       │  Free — catches bugs at write time
         └───────────────────────────┘
                  ┌───────┐
                  │  E2E  │  数量少、可信度高、速度慢、成本高
                 ─┴───────┴─
               ┌─────────────┐
               │ Integration  │  测试数量最多 — 投资回报率最佳
              ─┴─────────────┴─
            ┌───────────────────┐
            │       Unit        │  孤立逻辑测试、速度快、成本低
           ─┴───────────────────┴─
         ┌───────────────────────────┐
         │     Static Analysis       │  零成本 — 在编写代码时捕获bug
         └───────────────────────────┘

Test Categories

测试分类

CategoryWhat It TestsSpeedConfidenceCost
Static AnalysisTypes, syntax, lint rules, security patternsInstantLow-MediumFree
UnitIndividual functions/classes in isolationFastMediumLow
IntegrationMultiple units working togetherMediumHighMedium
E2EFull user flows through the real systemSlowVery HighHigh
分类测试内容速度可信度成本
Static Analysis类型、语法、代码规范、安全模式即时中低免费
Unit孤立的单个函数/类快中等低
Integration多个单元协同工作的场景中等高中等
E2E真实系统中的完整用户流程慢极高高

Beyond the Trophy

扩展分类

CategoryWhat It TestsWhen to Use
ContractAPI compatibility between servicesMicroservices / distributed systems
APIHTTP endpoints directlyREST/GraphQL APIs
PerformanceLoad, stress, scalabilityBefore launch, capacity planning
VisualUI appearance / regressionDesign systems, component libraries
AccessibilityWCAG compliance, screen readersAll user-facing apps
AcceptanceBusiness requirements (BDD)Stakeholder-facing features
ChaosSystem resilience under failureDistributed systems, microservices
分类测试内容使用场景
Contract服务间的API兼容性微服务/分布式系统
API直接测试HTTP端点REST/GraphQL API
Performance负载、压力、可扩展性上线前、容量规划
VisualUI外观/回归测试设计系统、组件库
AccessibilityWCAG合规性、屏幕阅读器适配所有面向用户的应用
Acceptance业务需求（BDD）面向利益相关者的功能
Chaos故障下的系统韧性分布式系统、微服务

Right-Sizing Your Tests

合理规划测试

The Trophy Distribution

测试占比分配

Allocate effort roughly proportional to the Trophy shape:
Category% of TestsRationale
Static AnalysisAlways onZero-cost, catches trivial bugs
Unit~20%Pure logic, algorithms, edge cases
Integration~50%Best confidence-per-dollar
E2E~20%Critical user journeys only
Other (contract, perf, a11y, visual)~10%As needed per project type
按照Test Trophy模型的形状大致分配精力：
分类测试占比理由
Static Analysis始终启用零成本，捕获低级bug
Unit~20%纯逻辑、算法、边缘场景
Integration~50%每单位成本的可信度最高
E2E~20%仅针对关键用户流程
其他（contract、perf、a11y、visual）~10%根据项目类型按需分配

When to Shift the Balance

调整测试平衡的场景

Project TypeEmphasizeReduce
Library / SDKUnit tests (public API surface)E2E (no UI)
MicroservicesContract + integrationE2E (too many services)
Monolithic web appIntegration + E2EContract (single deploy)
Design systemVisual + accessibilityPerformance
Real-time / tradingPerformance + unitVisual
Regulated / healthcareAcceptance (BDD) + integration—
项目类型重点关注减少投入
库/SDK单元测试（公共API层面）E2E测试（无UI场景）
微服务Contract测试 + 集成测试E2E测试（服务数量过多）
单体Web应用集成测试 + E2E测试Contract测试（单一部署单元）
设计系统Visual测试 + 可访问性测试性能测试
实时/交易系统性能测试 + 单元测试Visual测试
受监管/医疗系统验收测试（BDD） + 集成测试—

Cross-Platform Tool Landscape

跨平台工具生态

Static Analysis

Static Analysis

ToolLanguages
TypeScriptJS/TS (type checking)
ESLint / BiomeJS/TS (linting)
Roslyn AnalyzersC#
Pylint / Ruff / mypyPython
SemgrepMulti-language SAST
工具支持语言
TypeScriptJS/TS（类型检查）
ESLint / BiomeJS/TS（代码规范检查）
Roslyn AnalyzersC#
Pylint / Ruff / mypyPython
Semgrep多语言SAST

Unit Testing

Unit Testing

ToolLanguages
Vitest / JestJS/TS
xUnit / NUnit / MSTestC#
pytestPython
JUnit / TestNGJava
Go testGo
工具支持语言
Vitest / JestJS/TS
xUnit / NUnit / MSTestC#
pytestPython
JUnit / TestNGJava
Go testGo

Integration Testing

Integration Testing

ToolLanguages
TestcontainersJava, .NET, Node, Python, Go
Vitest / JestJS/TS
xUnit + WebApplicationFactoryC# / ASP.NET
pytestPython
工具支持语言
TestcontainersJava, .NET, Node, Python, Go
Vitest / JestJS/TS
xUnit + WebApplicationFactoryC# / ASP.NET
pytestPython

E2E Testing

E2E Testing

ToolPlatforms
PlaywrightWeb (Chromium, Firefox, WebKit)
CypressWeb (Chromium-based)
SeleniumWeb (all browsers)
AppiumMobile (iOS, Android)
MaestroMobile (iOS, Android)
工具支持平台
PlaywrightWeb（Chromium, Firefox, WebKit）
CypressWeb（基于Chromium）
SeleniumWeb（所有浏览器）
AppiumMobile（iOS, Android）
MaestroMobile（iOS, Android）

Contract Testing

Contract Testing

ToolType
PactConsumer-driven contracts
PactFlowBi-directional contract testing
Spring Cloud ContractJVM contract testing
工具类型
Pact消费者驱动的契约
PactFlow双向契约测试
Spring Cloud ContractJVM契约测试

API Testing

API Testing

ToolFormat
.http filesVS Code / JetBrains REST Client
BrunoGit-friendly API collections
Postman / NewmanCollections + CLI runner
REST Client (VS Code)Inline .http files
k6Scripted API + load testing
工具格式
.http filesVS Code / JetBrains REST Client
Bruno支持Git的API集合
Postman / Newman集合 + CLI运行器
REST Client (VS Code)内嵌.http文件
k6脚本化API + 负载测试

Performance Testing

Performance Testing

ToolType
k6 (Grafana)Load / stress (JS scripts)
JMeterLoad / stress (GUI + CLI)
GatlingLoad / stress (Scala/Java)
ArtilleryLoad / stress (YAML config)
LighthouseWeb performance audit
工具类型
k6 (Grafana)负载/压力测试（JS脚本）
JMeter负载/压力测试（GUI + CLI）
Gatling负载/压力测试（Scala/Java）
Artillery负载/压力测试（YAML配置）
LighthouseWeb性能审计

Visual Testing

Visual Testing

ToolIntegration
ChromaticStorybook visual regression
Percy (BrowserStack)Cross-browser visual diffs
BackstopJSCSS regression (headless)
Playwright screenshotsCustom visual assertions
工具集成方式
ChromaticStorybook视觉回归测试
Percy (BrowserStack)跨浏览器视觉差异对比
BackstopJSCSS回归测试（无头模式）
Playwright screenshots自定义视觉断言

Accessibility Testing

Accessibility Testing

ToolType
axe-core / @axe-core/playwrightAutomated WCAG checks
Pa11yCLI accessibility audits
LighthouseAccessibility scoring
Storybook addon-a11yComponent-level checks
工具类型
axe-core / @axe-core/playwright自动化WCAG检查
Pa11yCLI可访问性审计
Lighthouse可访问性评分
Storybook addon-a11y组件级检查

Acceptance Testing (BDD)

Acceptance Testing (BDD)

ToolLanguages
CucumberJava, JS, Ruby
SpecFlow / ReqnrollC#
BehavePython
GaugeMulti-language (Markdown specs)
GodogGo
工具支持语言
CucumberJava, JS, Ruby
SpecFlow / ReqnrollC#
BehavePython
Gauge多语言（Markdown规范）
GodogGo

Chaos Testing

Chaos Testing

ToolType
Chaos MonkeyRandom VM termination (Netflix)
GremlinSaaS fault injection platform
LitmusKubernetes chaos engineering (CNCF)
Chaos MeshKubernetes fault injection
ToxiproxyTCP proxy for network faults
AWS Fault Injection ServiceAWS-native chaos
Azure Chaos StudioAzure-native chaos
工具类型
Chaos Monkey随机VM终止（Netflix）
GremlinSaaS故障注入平台
LitmusKubernetes混沌工程（CNCF）
Chaos MeshKubernetes故障注入
Toxiproxy网络故障TCP代理
AWS Fault Injection ServiceAWS原生混沌测试
Azure Chaos StudioAzure原生混沌测试

Test Automation Architecture

测试自动化架构

CI Pipeline
  │
  ├── Static Analysis ──► ESLint + TypeScript + Semgrep (on every commit)
  │
  ├── Unit Tests ────────► Vitest / xUnit / pytest (on every commit)
  │
  ├── Integration Tests ─► Testcontainers + API tests (on every PR)
  │
  ├── Contract Tests ────► Pact verify (on every PR)
  │
  ├── E2E Tests ─────────► Playwright critical paths (on merge to main)
  │
  ├── Visual Tests ──────► Chromatic snapshot comparison (on every PR)
  │
  ├── A11y Tests ────────► axe-core in Playwright (on every PR)
  │
  ├── Performance Tests ─► k6 load tests (nightly / pre-release)
  │
  └── Chaos Tests ────────► Litmus / Gremlin experiments (pre-release / game days)
CI Pipeline
  │
  ├── Static Analysis ──► ESLint + TypeScript + Semgrep（每次提交时运行）
  │
  ├── Unit Tests ────────► Vitest / xUnit / pytest（每次提交时运行）
  │
  ├── Integration Tests ─► Testcontainers + API测试（每次PR时运行）
  │
  ├── Contract Tests ────► Pact verify（每次PR时运行）
  │
  ├── E2E Tests ─────────► Playwright关键路径测试（合并到主分支时运行）
  │
  ├── Visual Tests ──────► Chromatic快照对比（每次PR时运行）
  │
  ├── A11y Tests ────────► axe-core in Playwright（每次PR时运行）
  │
  ├── Performance Tests ─► k6负载测试（夜间/预发布时运行）
  │
  └── Chaos Tests ────────► Litmus / Gremlin实验（预发布/故障演练日运行）

Best Practices

最佳实践

  • Follow the Test Trophy shape — invest most in integration tests, not unit tests.
  • Run static analysis on every keystroke (IDE) and every commit (CI) — it's free confidence.
  • Write E2E tests only for critical user journeys — they're expensive to maintain.
  • Use contract tests instead of E2E for verifying service boundaries in microservices.
  • Use Testcontainers for integration tests that need real databases, message brokers, or caches.
  • Use .http files or Bruno for API testing that's version-controlled alongside the code.
  • Run performance tests regularly (nightly or pre-release), not just before launch.
  • Include accessibility testing in CI — axe-core catches >50% of WCAG violations automatically.
  • Use BDD/Gherkin for features where business stakeholders need to verify acceptance criteria.
  • Keep test data factories close to the tests — avoid shared global test fixtures.
  • Use chaos engineering to verify resilience assumptions — inject real faults in staging and production with controlled blast radius.
  • 遵循Test Trophy模型的比例 — 重点投资集成测试，而非单元测试。
  • 在IDE中实时运行静态分析，并在每次CI提交时运行 — 这是零成本的可信度提升手段。
  • 仅为关键用户流程编写E2E测试 — 这类测试维护成本极高。
  • 在微服务中，使用契约测试替代E2E测试来验证服务边界。
  • 对于需要真实数据库、消息队列或缓存的集成测试，使用Testcontainers。
  • 使用.http文件或Bruno进行API测试，确保测试与代码一起版本控制。
  • 定期运行性能测试（夜间或预发布时），而不仅仅是上线前。
  • 在CI中加入可访问性测试 — axe-core可自动捕获超过50%的WCAG违规问题。
  • 对于需要利益相关者验证验收标准的功能，使用BDD/Gherkin。
  • 测试数据工厂应贴近测试代码 — 避免使用共享的全局测试夹具。
  • 使用混沌工程验证系统韧性假设 — 在预发布和生产环境中注入可控的真实故障。