用途
TDD 技能用于在开发功能或修复缺陷时，通过测试驱动开发（Test-Driven Development）的红-绿-重构循环来指导编码。它适用于用户明确要求使用 TDD、提及“red-green-refactor”或希望以测试先行的方式构建功能的场景。
主要能力
- 行为驱动测试：强调测试应通过公共接口验证行为，而非耦合实现细节。好的测试读起来像规格说明，例如“用户可以使用有效购物车结账”，并且能在内部重构后继续通过。
- 避免水平切片：反对先写所有测试再写所有实现的做法，认为这会导致测试批量编写、测试想象的行为而非实际行为、测试对真实变化不敏感等问题。
- 垂直切片与追踪弹：采用一次一个测试、一次一个实现的增量方式，每个测试都基于上一轮循环中学到的内容。
- 四阶段工作流：包括规划、追踪弹、增量循环和重构。
- 每轮检查清单：确保测试描述行为、仅使用公共接口、能经受内部重构、代码最小化且无推测性功能。
使用方式
- 规划：在编写代码前，与用户确认接口变更、要测试的行为（按优先级）、识别深模块机会、设计可测试接口、列出要测试的行为（非实现步骤），并获得用户对计划的批准。
- 追踪弹：编写一个测试确认系统的一个行为。RED：写第一个行为的测试，测试失败；GREEN：写最小代码使其通过，测试通过。这证明路径端到端可用。
- 增量循环：对每个剩余行为，RED：写下一个测试，失败；GREEN：写最小代码使其通过。规则包括一次一个测试、仅写足够通过当前测试的代码、不预测未来测试、保持测试聚焦于可观察行为。
- 重构：所有测试通过后，寻找重构候选：提取重复、深化模块（将复杂性移到简单接口后）、自然应用 SOLID 原则、考虑新代码揭示了现有代码的什么。每次重构步骤后运行测试。绝不在 RED 状态下重构，先达到 GREEN。
适用场景
- 用户希望使用 TDD 构建功能或修复缺陷。
- 用户提及“red-green-refactor”或类似术语。
- 需要以测试先行方式确保代码行为正确且可维护的项目。
限制
- 无法测试所有内容，需与用户确认哪些行为最重要，聚焦关键路径和复杂逻辑，而非每个可能的边缘情况。
- 资料中未提供具体的安装命令、代码示例或平台支持信息。
- 资料中未提供收费、价格或效果保证等信息。