企业官网建设流程全解析

name: tdd-workflows-tdd-cycle
description: “Use when working with tdd workflows tdd cycle”
risk: critical
source: community
date_added: “2026-02-27”

何时使用此技能

• 处理 tdd workflows tdd cycle 任务或工作流时
• 需要关于 tdd workflows tdd cycle 的指导、最佳实践或检查清单时

何时不使用此技能

• 任务与 tdd workflows tdd cycle 无关时
• 你需要此范围之外的领域或工具时

说明

• 澄清目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可操作的步骤和验证方法。
• 如果需要详细示例，请打开resources/implementation-playbook.md。

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

[扩展思考：此工作流通过协调代理编排强制执行测试优先开发。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 的所有测试并验证它们通过。检查测试覆盖率指标。确保没有测试被意外破坏。”
• 输出：测试执行报告、覆盖率指标
• 关卡：在继续之前所有测试必须通过

阶段 4：REFACTOR - 改进代码质量

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. 对下一个测试重复

通过添加--incremental标志使用此方法，一次专注于一个测试。

测试套件模式

用于全面测试套件开发：

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

通过添加--suite标志使用此方法进行批量测试开发。

验证检查点

RED 阶段验证

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

GREEN 阶段验证

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

REFACTOR 阶段验证

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

覆盖率报告

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

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

失败恢复

如果 TDD 纪律被破坏：

1. 立即停止
2. 识别哪个阶段被违反
3. 回滚到最后一个有效状态
4. 从正确的阶段恢复
5. 记录学到的经验教训

TDD 度量跟踪

跟踪并报告：

• 每个阶段的时间（红/绿/重构）
• 测试-实现循环次数
• 覆盖率进展
• 重构频率
• 缺陷逃逸率

要避免的反模式

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

成功标准

• 100% 的代码是测试优先编写的
• 所有测试持续通过
• 覆盖率超过阈值
• 代码复杂度在限制范围内
• 覆盖的代码零缺陷
• 清晰的测试文档
• 快速的测试执行（单元测试 < 5 秒）

注意事项

• 强制执行严格的红-绿-重构纪律
• 每个阶段必须完成才能进入下一阶段
• 测试就是规格说明
• 如果测试难以编写，说明设计需要改进
• 重构不是可选的
• 保持测试执行快速
• 测试应该独立且隔离

针对以下内容的 TDD 实现：$ARGUMENTS

局限性

• 仅在任务明确匹配上述范围时使用此技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需的输入、权限、安全边界或成功标准，请停下来询问澄清。