tdd-workflows-tdd-cycle

适用于以下情况

• 处理 TDD 工作流、TDD 周期任务或工作流
• 需要有关 TDD 工作流、TDD 周期的指导、最佳实践或检查清单

以下情况不适用

• 任务与 TDD 工作流、TDD 周期无关
• 需要使用超出此范围的其他领域或工具

说明

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可执行的步骤和验证方法。
• resources/implementation-playbook.md 未随附；请报告无法获取此依赖项，而不要编造其内容。

执行全面的测试驱动开发（TDD）工作流，严格遵循红—绿—重构纪律：

[扩展思考：此工作流通过协调 Agent 编排来强制执行测试优先开发。TDD 周期的每个阶段都必须严格遵守，包括先验证失败、逐步实现和持续重构。此工作流支持单个测试和测试套件两种方式，并可配置覆盖率阈值。]

主机与证据范围

下文提到的 Task/subagent 类型是集成示例，并不保证已安装。请在用户和仓库约束范围内，使用主机支持的工作流。覆盖率和复杂度阈值仅是初始评估标准，并非普遍适用的正确性门槛。RED 阶段现有测试不必失败：请验证每个新增测试都因预期缺失的行为而失败，同时保持现有测试通过。切勿为了恢复 TDD 阶段而回滚无关改动或用户改动。

配置

覆盖率阈值

• 最低行覆盖率：80%
• 最低分支覆盖率：75%
• 关键路径覆盖率：100%

重构触发条件

• 圈复杂度 > 10
• 方法长度 > 20 行
• 类长度 > 200 行
• 重复代码块 > 3 行

阶段 1：测试规范与设计

1. 需求分析

• 使用 Task 工具，subagent_type="comprehensive-review::architect-review"
• 提示词："分析以下需求：$ARGUMENTS。定义验收标准，识别边界情况，并创建测试场景。输出全面的测试规范。"
• 输出：测试规范、验收标准、边界情况矩阵
• 验证：确保所有需求都有对应的测试场景

2. 测试架构设计

• 使用 Task 工具，subagent_type="unit-testing::test-automator"
• 提示词："根据测试规范，为以下内容设计测试架构：$ARGUMENTS。定义测试结构、固定装置、模拟对象和测试数据策略。确保测试易于维护且可测试。"
• 输出：测试架构、固定装置设计、模拟策略
• 验证：架构支持隔离、快速、可靠的测试

阶段 2：RED——编写失败测试

3. 编写单元测试（失败）

• 使用 Task 工具，subagent_type="unit-testing::test-automator"
• 提示词："为以下内容编写失败的单元测试：$ARGUMENTS。测试初始时必须失败。包含边界情况、错误场景和正常流程。不要实现生产代码。"
• 输出：失败的单元测试、测试文档
• 关键：验证所有测试都因预期错误消息而失败

4. 验证测试失败

• 使用 Task 工具，subagent_type="tdd-workflows::code-reviewer"
• 提示词："验证以下内容的所有测试是否正确失败：$ARGUMENTS。确保失败原因正确（缺少实现，而非测试错误）。确认没有误报。"
• 输出：测试失败验证报告
• 门槛：所有测试都按预期失败后，才能继续

阶段 3：GREEN——让测试通过

5. 最小化实现

• 使用 Task 工具，subagent_type="backend-development::backend-architect"
• 提示词："实现最少量的代码，让以下内容的测试通过：$ARGUMENTS。只专注于让测试变绿。不要添加额外功能或优化。保持简单。"
• 输出：可运行的最小化实现
• 约束：代码不得超出通过测试所需的范围

6. 验证测试是否通过

• 使用 Task 工具，设置 subagent_type="unit-testing::test-automator"
• 提示词："为以下内容运行所有测试：$ARGUMENTS，并验证测试是否通过。检查测试覆盖率指标。确保没有意外破坏任何测试。"
• 输出：测试执行报告、覆盖率指标
• GATE：所有测试必须通过后才能继续

阶段 4：重构——提升代码质量

7. 代码重构

• 使用 Task 工具，设置 subagent_type="tdd-workflows::code-reviewer"
• 提示词："在保持测试通过的前提下，重构以下内容的实现：$ARGUMENTS。应用 SOLID 原则，消除重复，改进命名并优化性能。每次重构后都运行测试。"
• 输出：重构后的代码、重构报告
• 约束：整个过程中测试必须始终通过

8. 测试重构

• 使用 Task 工具，设置 subagent_type="unit-testing::test-automator"
• 提示词："重构以下内容的测试：$ARGUMENTS。消除重复测试，改进测试名称，提取通用测试夹具，并提升测试可读性。确保测试仍提供相同的覆盖率。"
• 输出：重构后的测试、改进后的测试结构
• 验证：覆盖率指标不变或有所提升

阶段 5：集成测试和系统测试

9. 编写集成测试（先让测试失败）

• 使用 Task 工具，设置 subagent_type="unit-testing::test-automator"
• 提示词："为以下内容编写会失败的集成测试：$ARGUMENTS。测试组件交互、API 合约和数据流。测试必须一开始就失败。"
• 输出：失败的集成测试
• 验证：测试因缺少集成逻辑而失败

10. 实现集成

• 使用 Task 工具，设置 subagent_type="backend-development::backend-architect"
• 提示词："为以下内容实现集成代码：$ARGUMENTS，使集成测试通过。重点关注组件交互和数据流。"
• 输出：集成实现
• 验证：所有集成测试均通过

阶段 6：持续改进循环

11. 性能测试和边界情况测试

• 使用 Task 工具，设置 subagent_type="unit-testing::test-automator"
• 提示词："为以下内容添加性能测试和其他边界情况测试：$ARGUMENTS。包括压力测试、边界测试和错误恢复测试。"
• 输出：扩展后的测试套件
• 指标：提升测试覆盖率和场景覆盖率

12. 最终代码审查

• 使用 Task 工具，设置 subagent_type="comprehensive-review::architect-review"
• 提示词："对以下内容进行全面审查：$ARGUMENTS。验证是否遵循了 TDD 流程，检查代码质量、测试质量和覆盖率。提出改进建议。"
• 输出：审查报告、改进建议
• 操作：在保持测试通过的同时落实关键建议

增量开发模式

逐个测试进行开发：

1. 编写一个失败的测试
2. 只让该测试通过
3. 如有需要则进行重构
4. 对下一个测试重复上述步骤

使用自然语言请求增量模式；不包含可执行的 CLI 或 --incremental 解析器。

测试套件模式

全面开发测试套件：

1. 为某个功能或模块编写所有测试（使其失败）
2. 编写代码以通过所有测试
3. 重构整个模块
4. 添加集成测试

使用自然语言请求测试套件模式；不包含可执行的 CLI 或 --suite 解析器。

验证检查点

RED 阶段验证

• 在实现前编写所有测试
• 所有测试均以有意义的错误消息失败
• 测试失败是因为缺少实现
• 没有测试意外通过

GREEN 阶段验证

• 所有测试均通过
• 没有超出测试要求的额外代码
• 覆盖率达到最低阈值
• 没有为使测试通过而修改测试

REFACTOR 阶段验证

• 重构后所有测试仍然通过
• 代码复杂度降低
• 消除重复
• 性能得到提升或保持不变
• 测试可读性得到提升

覆盖率报告

每个阶段结束后生成覆盖率报告：

• 行覆盖率
• 分支覆盖率
• 函数覆盖率
• 语句覆盖率

失败恢复

如果违反了 TDD 规范：

1. 立即停止
2. 确定违反了哪个阶段
3. 回滚到最后一个有效状态
4. 从正确的阶段继续
5. 记录经验教训

TDD 指标跟踪

跟踪并报告：

• 各阶段（Red/Green/Refactor）耗时
• 测试与实现的循环次数
• 覆盖率变化
• 重构频率
• 缺陷逃逸率

应避免的反模式

• 在测试之前编写实现
• 编写无需修改即可通过的测试
• 跳过重构阶段
• 在没有测试的情况下编写多个功能
• 修改测试以使其通过
• 忽略失败的测试
• 在实现之后编写测试

成功标准

• 100% 的代码均先编写测试
• 所有测试持续通过
• 覆盖率超过阈值
• 代码复杂度在限制范围内
• 报告发现的缺陷/问题；覆盖率和测试通过并不能证明没有缺陷
• 测试文档清晰
• 测试执行快速（单元测试少于 5 秒）

注意事项

• 严格遵循 RED-GREEN-REFACTOR 规范
• 每个阶段都必须完成后才能进入下一阶段
• 测试即规范
• 如果测试难以编写，说明设计需要改进
• 重构不是可选项
• 保持测试执行快速
• 测试应彼此独立、相互隔离

TDD 实现对象：$ARGUMENTS

示例

用户请求：

使用 red-green-refactor 循环实现此行为，并展示失败的测试、最小修复方案以及最终通过的检查。

限制

• 仅当任务明确符合上述范围时才使用此技能。
• 请勿将输出视为替代特定环境验证、测试或专家审查的方案。
• 如果缺少必要的输入、权限、安全边界或成功标准，请停止并请求澄清。