acceptance-testing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Acceptance Testing

验收测试

Overview

概述

Acceptance-driven backpressure connects specification acceptance criteria directly to test requirements, creating a validation chain that prevents premature completion claims. The system cannot cheat — you cannot claim a feature is done unless tests derived from spec acceptance criteria actually pass.

Announce at start: "I'm using the acceptance-testing skill to validate against specification criteria."

验收驱动反压将规范验收标准直接与测试要求关联，构建了一条可防止提前声称完成的验证链。这套体系无法作弊——除非从规范验收标准衍生的测试全部通过，否则你不能声称某个功能已完成。

启动时声明： "我正在使用验收测试技能对照规范标准进行验证。"

The Backpressure Chain

反压链

+------------+     derives      +------------+     validates    +------------+
|   SPECS    |---------------->|   TESTS    |---------------->|   CODE     |
|            |                  |            |                  |            |
| Acceptance |                  | Test cases |                  | Must pass  |
| Criteria   |                  | from AC    |                  | all tests  |
+------------+                  +------------+                  +------------+
      ^                                                              |
      |                    backpressure                               |
      +--------------------------------------------------------------+
      If tests fail, implementation must change (not the spec or test)

+------------+     derives      +------------+     validates    +------------+
|   SPECS    |---------------->|   TESTS    |---------------->|   CODE     |
|            |                  |            |                  |            |
| Acceptance |                  | Test cases |                  | Must pass  |
| Criteria   |                  | from AC    |                  | all tests  |
+------------+                  +------------+                  +------------+
      ^                                                              |
      |                    backpressure                               |
      +--------------------------------------------------------------+
      If tests fail, implementation must change (not the spec or test)

Phase 1: Extract Acceptance Criteria

阶段1：提取验收标准

Goal: From each specification file, extract all Given/When/Then acceptance criteria.

目标： 从每份规范文件中提取所有Given/When/Then格式的验收标准。

Actions

执行动作

Locate all specification files (
```
specs/*.md
```
)
Extract every acceptance criterion with its ID
Document in structured format

定位所有规范文件（
```
specs/*.md
```
）
提取每条验收标准及其ID
以结构化格式归档

Example Extraction

提取示例

markdown

undefined

markdown

undefined

From spec: 01-color-extraction.md

AC-1: Extract dominant colors

Given an uploaded image (PNG, JPG, or WebP)
When color extraction is triggered
Then 5-10 dominant colors are returned
And each color includes hex, RGB, and HSL representations

Given an uploaded image (PNG, JPG, or WebP)
When color extraction is triggered
Then 5-10 dominant colors are returned
And each color includes hex, RGB, and HSL representations

AC-2: Handle invalid images

Given a corrupted or unsupported file
When color extraction is attempted
Then an appropriate error is returned
And no partial results are produced

undefined

Given a corrupted or unsupported file
When color extraction is attempted
Then an appropriate error is returned
And no partial results are produced

undefined

STOP — HARD-GATE: Do NOT proceed to Phase 2 until:

停止 — 硬关卡：满足以下条件前不得进入阶段2：

All spec files are located and read
Every acceptance criterion is extracted with an ID
Criteria are in Given/When/Then format
No criteria are ambiguous (if ambiguous, clarify with spec author)

所有规范文件均已定位并读取
每条验收标准都已提取并附带ID
标准均采用Given/When/Then格式
无歧义标准（如有歧义，需与规范作者澄清）

Phase 2: Derive Test Cases

阶段2：衍生测试用例

Goal: Map every acceptance criterion to at least one test case.

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: Every acceptance criterion must have at least one   │
│  corresponding test. No exceptions. If a criterion has no       │
│  test, the feature is NOT complete.                             │
└─────────────────────────────────────────────────────────────────┘

目标： 为每条验收标准匹配至少一条测试用例。

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: Every acceptance criterion must have at least one   │
│  corresponding test. No exceptions. If a criterion has no       │
│  test, the feature is NOT complete.                             │
└─────────────────────────────────────────────────────────────────┘

Traceability Table

可追溯表

Acceptance Criterion	Test Type	Test Description	Test File:Line
AC-1: Extract dominant colors	Integration	Upload valid image, verify 5-10 colors with hex/RGB/HSL	test/color.test.js:15
AC-2: Handle invalid images	Integration	Upload corrupted file, verify error, verify no partial data	test/color.test.js:42

验收标准	测试类型	测试描述	测试文件:行号
AC-1: 提取主色	集成测试	上传有效图片，验证返回5-10个带hex/RGB/HSL格式的颜色	test/color.test.js:15
AC-2: 处理无效图片	集成测试	上传损坏文件，验证返回错误、无部分数据输出	test/color.test.js:42

Decision Table: Test Type for Acceptance Criteria

决策表：验收标准对应的测试类型

Criterion Type	Test Type	Rationale
Data input/output behavior	Integration	Tests real data flow
Error handling behavior	Integration	Tests error paths end-to-end
Performance requirement	Load test	Requires measurement under load
UI behavior	E2E (Playwright)	Tests real browser interaction
Subjective quality	LLM-as-judge	Cannot be deterministically tested
Security requirement	Integration + security test	Tests authorization and input validation

标准类型	测试类型	逻辑说明
数据输入输出行为	集成测试	测试真实数据流
错误处理行为	集成测试	端到端测试错误路径
性能要求	负载测试	需要在负载下测量性能
UI行为	E2E (Playwright)	测试真实浏览器交互
主观质量	LLM-as-judge	无法通过确定性方式测试
安全要求	集成测试+安全测试	测试授权与输入校验

STOP — HARD-GATE: Do NOT proceed to Phase 3 until:

停止 — 硬关卡：满足以下条件前不得进入阶段3：

Every acceptance criterion has at least one test mapped
Test types are appropriate for the criterion type
Test file locations are identified

每条验收标准都至少匹配了一条测试
测试类型与标准类型适配
测试文件位置已确认

Phase 3: Write Tests Before Implementation

阶段3：实现前编写测试

Goal: Write acceptance tests that will fail until the feature is correctly implemented.

目标： 编写验收测试，在功能正确实现前这些测试会始终失败。

Actions

执行动作

This phase integrates with

test-driven-development

Write test from acceptance criterion (RED)
Implement feature to pass test (GREEN)
Refactor while keeping test green (REFACTOR)

本阶段与

test-driven-development

流程集成：

基于验收标准编写测试（红）
实现功能通过测试（绿）
重构代码并保持测试通过（重构）

Behavioral Outcome Focus

聚焦行为结果

Verify This (Behavioral)	NOT This (Implementation)
"5-10 colors are returned"	"K-means runs with k=8"
"Response time < 200ms"	"Cache is hit on second call"
"Error message is user-friendly"	"CustomError class is thrown"
"Data persists across sessions"	"PostgreSQL INSERT executes"
"UI updates within 500ms"	"WebSocket message is received"

验证内容（行为层）	不要验证（实现层）
"返回5-10个颜色"	"K-means算法k值设为8"
"响应时间<200ms"	"第二次调用命中缓存"
"错误信息对用户友好"	"抛出CustomError类实例"
"数据跨会话持久化存储"	"执行PostgreSQL INSERT语句"
"UI在500ms内更新"	"收到WebSocket消息"

STOP — HARD-GATE: Do NOT proceed to Phase 4 until:

停止 — 硬关卡：满足以下条件前不得进入阶段4：

All acceptance tests are written
Tests fail before implementation (RED confirmed)
Tests verify behavioral outcomes, not implementation details

所有验收测试已编写完成
实现前测试运行失败（已确认红状态）
测试验证的是行为结果，而非实现细节

Phase 4: Validation Gates

阶段4：验证关卡

Goal: Before claiming any task complete, ALL gates must pass.

Gate	Check	Tool	Required
Unit tests	All pass	Test runner	Always
Integration tests	All pass	Test runner	Always
Acceptance tests	All AC-derived tests pass	Test runner	Always
Build	Compiles without errors	Build tool	Always
Lint	No violations	Linter	Always
Typecheck	No type errors	Type checker	When applicable

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: ACCEPTANCE                                         │
│                                                                 │
│  Cannot claim completion without ALL acceptance tests passing.  │
│  If any acceptance test fails, the feature is NOT done.        │
│  Fix the implementation, not the spec or the test.             │
└─────────────────────────────────────────────────────────────────┘

目标： 声称任何任务完成前，所有关卡必须全部通过。

关卡	检查项	工具	是否必填
单元测试	全部通过	测试运行器	总是必填
集成测试	全部通过	测试运行器	总是必填
验收测试	所有验收标准衍生的测试全部通过	测试运行器	总是必填
构建	编译无错误	构建工具	总是必填
代码检查	无违规项	Linter	总是必填
类型检查	无类型错误	类型检查器	适用场景下必填

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: ACCEPTANCE                                         │
│                                                                 │
│  Cannot claim completion without ALL acceptance tests passing.  │
│  If any acceptance test fails, the feature is NOT done.        │
│  Fix the implementation, not the spec or the test.             │
└─────────────────────────────────────────────────────────────────┘

STOP — HARD-GATE: Do NOT proceed to Phase 5 until:

停止 — 硬关卡：满足以下条件前不得进入阶段5：

All validation gates pass
Acceptance tests pass with green status
No gates are skipped or marked as "will fix later"

所有验证关卡通过
验收测试全部通过，状态为绿
无关卡被跳过或标记为"后续修复"

Phase 5: Traceability Report

阶段5：可追溯报告

Goal: Produce a report linking every spec criterion to its test and result.

目标： 生成报告，将每条规范标准与其测试和结果关联起来。

Report Template

报告模板

markdown

undefined

markdown

undefined

Acceptance Test Report

验收测试报告

Spec	Criterion	Test	Status
01-color-extraction.md	AC-1: Extract dominant colors	test/color.test.js:15	PASS
01-color-extraction.md	AC-2: Handle invalid images	test/color.test.js:42	PASS
02-palette-rendering.md	AC-1: Render palette grid	test/palette.test.js:8	PASS

规范文件	验收标准	测试	状态
01-color-extraction.md	AC-1: 提取主色	test/color.test.js:15	通过
01-color-extraction.md	AC-2: 处理无效图片	test/color.test.js:42	通过
02-palette-rendering.md	AC-1: 渲染调色板网格	test/palette.test.js:8	通过

Summary

汇总

Total criteria: N
Tested: N
Passing: N
Failing: 0
Coverage: 100%

---

总标准数: N
已测试: N
已通过: N
失败: 0
覆盖率: 100%

---

Anti-Patterns / Common Mistakes

反模式/常见错误

Anti-Pattern	Why It Is Wrong	Correct Approach
Changing specs to match implementation	Defeats the purpose of specification	Fix the implementation, not the spec
Skipping edge case criteria	Edge cases cause production bugs	ALL acceptance criteria get tests
Testing implementation details	Brittle tests that break on refactor	Test observable behavioral outcomes
Claiming "tests pass" without acceptance tests	Unit tests alone are insufficient	Acceptance tests are a separate, required category
Writing acceptance tests after implementation	Tests shaped to pass, not to specify	Write BEFORE implementation (TDD)
Deferring acceptance tests to "later"	Later never comes	Write them in Phase 2, before coding
Marking failing tests as "known issues"	Hides incomplete implementation	Fix the code until tests pass

反模式	错误原因	正确做法
修改规范匹配实现	违背了制定规范的目的	修复实现，而非修改规范
跳过边缘场景标准	边缘场景会导致生产环境故障	所有验收标准都需配套测试
测试实现细节	测试易脆，重构时容易失效	测试可观测的行为结果
无验收测试就声称"测试通过"	仅单元测试不足以验证功能	验收测试是独立的必填测试类别
实现完成后才编写验收测试	测试会被设计为适配现有实现，而非定义要求	实现前编写测试（TDD）
把验收测试推迟到"以后"	"以后"永远不会来	在阶段2编写，编码前完成
将失败测试标记为"已知问题"	掩盖未完成的实现	修复代码直到测试通过

Rationalization Prevention

防止合理化借口

Excuse	Reality
"The unit tests cover this"	Unit tests test components in isolation; acceptance tests verify integrated behavior
"The spec is obvious, no need for formal tests"	Obvious specs still need verifiable tests
"We can manually verify this"	Manual verification is not repeatable or trustworthy
"The acceptance criteria are too vague to test"	Clarify the criteria; vague specs produce vague code
"This is just a cosmetic change"	Cosmetic changes can break layout, accessibility, and UX

借口	实际情况
"单元测试已经覆盖了"	单元测试测试的是隔离的组件；验收测试验证的是集成后的行为
"规范很明显，不需要正式测试"	再明显的规范也需要可验证的测试
"我们可以人工验证"	人工验证不可重复，可信度低
"验收标准太模糊没法测试"	先澄清标准；模糊的规范会产出模糊的代码
"这只是个样式改动"	样式改动可能破坏布局、可访问性和用户体验

Integration Points

集成点

Skill	Relationship
`spec-writing`	Acceptance criteria come from specs
`test-driven-development`	TDD cycle uses acceptance-derived tests
`llm-as-judge`	For subjective criteria that cannot be deterministically tested
`verification-before-completion`	Final verification includes acceptance test check
`autonomous-loop`	Exit gate requires acceptance tests passing
`code-review`	Review checks acceptance test coverage
`planning`	Plan includes acceptance test writing as explicit tasks

技能	关联关系
`spec-writing`	验收标准来自规范
`test-driven-development`	TDD循环使用验收衍生的测试
`llm-as-judge`	用于无法确定性测试的主观标准
`verification-before-completion`	最终验证包含验收测试检查
`autonomous-loop`	退出关卡要求验收测试通过
`code-review`	评审检查验收测试覆盖率
`planning`	规划中将验收测试编写列为明确任务

Skill Type

技能类型

RIGID — The backpressure chain must not be bypassed. Every acceptance criterion must have a test. No completion without passing acceptance tests. Fix the implementation, not the spec or the test.

刚性 — 反压链不可绕过。每条验收标准必须配套测试。验收测试未通过不得声称完成。修复实现，而非修改规范或测试。