requirements-clarification

TDD 需求澄清

目的

编写测试之前（RED 阶段），确保对需求的理解足够充分，以便：

1. 知道要测试什么行为
2. 找出边界情况和边界值
3. 理解验收标准
4. 避免因误解需求而返工

何时使用

遇到以下情况时，启动澄清：

• 功能描述少于 2 句话
• 未提供验收标准
• 存在“应妥善处理错误”之类的模糊表述
• 有业务逻辑，但未定义具体规则
• 未提供输入/输出示例

何时跳过

遇到以下情况时，跳过澄清：

• 需求明确规定了验收标准
• 用户提供了详细的测试场景
• 简单的 CRUD，且架构清晰
• Bug 修复有明确的复现步骤
• 用户要求“跳过澄清”或“直接继续”

问题类别

1. 功能需求

问题	目的
主要的正常流程行为是什么？	确定主要测试场景
此功能接受哪些输入？	定义参数验证测试
预期输出/结果是什么？	明确断言预期
应产生哪些副作用？	找出集成点
是否有业务规则或约束？	找出验证逻辑

2. 边界情况和边界值

问题	目的
输入为 null/空值时会发生什么？	空值处理测试
边界值（最小值/最大值）是什么？	边界条件测试
必需的依赖项不可用时会怎样？	错误处理测试
是否存在并发或时序方面的问题？	线程安全测试

3. 错误处理

问题	目的
应在何时抛出哪些异常？	异常测试
应如何处理无效输入？	验证测试
用户应看到哪些错误消息？	用户反馈测试

4. 技术澄清

问题	目的
已有哪些接口/抽象？	了解依赖项
应遵循哪些现有模式？	与代码库保持一致
是否有可供参考的现有测试？	保持测试风格一致
目标测试范围是什么（单元/集成）？	组织测试

澄清工作流

┌─────────────────────────────────────────────────────────────────┐
│                    CLARIFICATION PHASE                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐      │
│  │   Analyze    │───▶│   Identify   │───▶│   Present    │      │
│  │ Requirements │    │    Gaps      │    │  Questions   │      │
│  └──────────────┘    └──────────────┘    └──────────────┘      │
│                                               │                  │
│                    ┌──────────────┐           │                  │
│                    │   Collect    │◀──────────┘                  │
│                    │   Answers    │                              │
│                    └──────────────┘                              │
│                           │                                      │
│                    ┌──────────────┐                              │
│                    │  Sufficient? │                              │
│                    └──────────────┘                              │
│                      │         │                                 │
│                     YES        NO                                │
│                      │         │                                 │
│                      ▼         └──────▶ Ask Follow-up            │
│               ┌──────────────┐                                   │
│               │ Proceed to   │                                   │
│               │  RED Phase   │                                   │
│               └──────────────┘                                   │
│                                                                 │
│  EXIT: Requirements clear enough to define test scenarios        │
└─────────────────────────────────────────────────────────────────┘

输出模板

澄清后，记录对需求的理解：

## Clarified Requirements for {Feature}

### Understanding Summary
{Brief summary of what the feature should do}

### Inputs and Outputs
- **Inputs**: {List with types}
- **Outputs**: {Expected results}
- **Validation Rules**: {Business rules}

### Identified Test Scenarios
| Scenario Type | Description | Priority |
|---------------|-------------|----------|
| Happy Path | {description} | High |
| Edge Case | {description} | Medium |
| Error Case | {description} | Medium |
| Boundary | {description} | Medium |

### Ready for RED Phase

最少问题（始终考虑）

1. 正常流程的预期行为是什么？
2. 接受哪些输入，会产生哪些输出？
3. 应如何处理错误/无效输入？