tdd

TDD

将此技能用作单用户工作流。不要引入工作者、任务分配或团队协作等概念。

核心规则

• 实施前，先阅读请求、相关代码和约束。
• 编写生产代码前，先定义完成标准。
• 如果任务支持自动化测试，优先采用红灯阶段。
• 不要默认采用 E2E。仅在明确要求、任务约定已有要求，或低成本验证无法覆盖验收风险时使用 E2E。
• 如果任务需要设计测试用例、规划回归测试、覆盖验收标准或开展更广泛的 QA 执行，请调用 qa-expert，而不是将此技能扩展为完整的 QA 工作流。
• 如果不适合使用自动化测试，请在实施前定义手动验证步骤。
• 验证完成前，不要将工作视为完成。
• 如果跳过验证，请明确说明原因和剩余风险。

工作流

按以下顺序执行：

1. 阅读上下文
2. 定义验收标准
3. 条件允许时编写失败测试
4. 实施
5. 验证
6. 总结

除非前一步已明确完成，否则不要跳到后续步骤。

步骤 1：阅读上下文

修改前，检查请求和周边实现。

确认：

• 目标
• 范围
• 约束
• 非目标
• 现有验证选项

如果请求含糊不清，请先停止并消除歧义，再继续。

步骤 2：定义验收标准

实施前编写验收标准。

涵盖：

• 预期行为
• 边界情况
• 失败情况
• 可观察的完成条件

如果尚无法编写验收标准，则任务还不适合进入实施阶段。

步骤 3：条件允许时编写失败测试

如果任务支持自动化验证，请在实施前编写或更新测试。

确保进入真实的红灯阶段：

• 断言新行为
• 当前代码未通过该断言
• 预期结果清晰明确

如果自动化测试不适用，请在继续之前明确规定手动验证步骤。

步骤 4：实施

根据验收标准和验证计划进行实施。

除非先更新验收标准，否则不要在实施过程中扩大范围。

步骤 5：验证

按以下顺序采用最可靠的验证方式：

1. 现有自动化测试
2. 为此次变更新增的自动化测试
3. 有明确步骤和预期结果、可重复执行的手动验证
4. 仅在当前环境中无法进行验证时标记为 skipped

E2E 不是默认的验证方式。除非明确要求 E2E，或验收风险无法通过其他方式覆盖，否则优先采用成本较低的检查方式。

如果验证期间需要专门设计测试用例、执行回归测试或开展更广泛的 QA 覆盖，请调用 qa-expert。

如果验证失败，请返回实施阶段并修复问题，再进行总结。

步骤 6：总结

结束时必须且只能使用以下一种结果：

• passed
• failed
• skipped

总结时请包含：

• 变更内容的简要说明
• 使用的验证方式
• 结果
• 如有剩余风险，请予以说明

如果结果为 skipped，请说明原因，以及未进行验证带来的具体风险。

失败条件

遇到以下情况时，必须先停止并解决问题，再进行实施：

• 需求不清晰
• 缺少验收标准
• 未定义验证策略

遇到以下情况时，返回相应步骤并继续处理：

• 测试意外失败
• 验证命令失败
• 手动验证未满足验收标准

可选产物

仅在有帮助时使用轻量级产物：

• proposal.md
• design.md
• tests.md
• 明确的验证命令

除非项目已有固定目录结构，否则不要强制要求采用固定目录结构。