用途
该技能用于指导在实现任何功能或修复缺陷之前，先编写测试的测试驱动开发（TDD）流程。核心原则为：写测试、看它失败、写最小代码让它通过；若没有亲眼看到测试失败，就无法确认测试测的是正确的东西。
主要能力
- 提供红-绿-重构（Red-Green-Refactor）循环的明确步骤与验证要求。
- 强调铁律：没有先失败的测试，绝不写生产代码；若先写了代码，应删除并重新开始。
- 列举适用场景与例外情况：新功能、缺陷修复、重构、行为变更应始终使用；一次性原型、生成代码、配置文件可例外，但须征求人类伙伴同意。
- 提供好测试与坏测试的对比示例，说明测试命名、最小化、真实行为和意图表达的重要性。
- 解释测试顺序为何重要，并逐条驳斥“事后补测试”“已经手工测过”“删除已花费数小时的工作很浪费”“TDD 太教条”等常见合理化借口。
- 给出红旗信号清单，一旦出现即应停止并从头开始。
- 提供缺陷修复的完整示例（空邮箱被接受），展示 RED、验证 RED、GREEN、验证 GREEN、REFACTOR 各步骤。
- 提供完成前核对清单和遇到困难时的应对建议。
- 说明与调试的结合：发现缺陷后先写复现缺陷的失败测试，再走 TDD 循环，避免在没有测试的情况下修缺陷。
- 提示在添加模拟或测试工具时阅读相关文档（如 @testing-anti-patterns.md、@testing-strategy.md）以避免反模式。
使用方式
按照红-绿-重构循环执行：
- RED：写一个最小测试，只测一个行为，命名清晰，使用真实代码（除非不可避免，否则不用模拟）。
- 验证 RED：运行测试，确认它以预期方式失败（失败而非报错），失败原因是功能缺失而不是拼写错误。
- GREEN：写最简单能让测试通过的代码，不添加额外功能、不重构其他代码。
- 验证 GREEN：再次运行测试，确认通过、其他测试仍通过、输出干净无错误和警告。
- REFACTOR：在通过之后才清理重复、改进命名、提取辅助方法，保持测试通过，不添加新行为。
- 重复：为下一个功能写下一个失败测试。
资料中给出了 Rails 项目的命令示例：bin/rails test test/models/retry_test.rb、bin/rails test test/models/user_test.rb。
适用场景
适用于新功能开发、缺陷修复、重构和行为变更。也适用于发现缺陷后的调试：先写复现缺陷的失败测试，再按 TDD 循环修复，以确保修复被测试证明并防止回归。
限制
例外情况仅限于一次性原型、生成代码和配置文件，且需要征求人类伙伴同意。若无法勾选完成前核对清单的所有项，说明跳过了 TDD，应重新开始。此外，遇到困难（如不知道怎么测试、测试太复杂、必须模拟一切、测试初始化庞大）时，资料给出了对应建议：写出期望的 API、先写断言、询问人类伙伴、简化接口、使用依赖注入、提取辅助方法或简化设计。是否包含官方文档、价格或平台信息，暂未提供。