用途：在实现新功能或修复缺陷时采用 TDD 方法，先由需求定义测试规范，再以最小实现让测试通过，最后在绿灯状态下重构。文档将其定位为跨语言可用的开发方法论，并列出语言相关的测试运行器、属性测试、覆盖率与变异工具作为框架参考。
主要能力与工作流：
- 创建：按错误用例、边界用例、正常路径、属性测试的顺序编写会失败的测试。
- 红灯：运行测试并确认全部失败；若有测试通过，说明测试有误或行为已存在。
- 绿灯：用最小代码让测试通过，不做额外优化或清理。
- 重构：仅在全部测试通过后进行结构整理，行为改动与结构改动分开，每次改动后重跑测试。
规则与门槛：强制先设计测试、红灯先于绿灯、错误处理先于成功路径、一次只写一个失败测试、只在绿灯时重构。验证门槛中，测试文件存在、红灯状态、绿灯状态为阻塞项；行覆盖率不低于 80%、审查变异分数为非阻塞。退出码包括 0 完成、11 未检测到测试框架、12 测试编译失败、13 测试未失败、14 实现后测试仍失败、15 重构后回归失败。
适用场景：需求明确的新功能、修复缺陷前先写失败测试、重构前确保覆盖、API 契约（接口而非内部实现）、属性不变量、遗留代码修改前加入特征化测试。不适用：探索性原型与 spike、一次性脚本与数据迁移、纯视觉 UI 布局、高度实验性算法研究、寿命不足一周的丢弃代码。
测试替身与反模式：文档给出桩、mock、fake、spy 的层级，规则是只模拟外部依赖，不模拟核心领域逻辑；反模式包括事后补测试、测试实现细节、过度 mock、跳过红灯、追求 100% 覆盖率、在红灯时重构、由测试导致架构损伤、无治理的快照膨胀。另介绍内向外（经典/底特律）与外向内（伦敦/mock 派）两种流派，并说明按场景取舍。参考材料涉及 mocking、接口设计、重构、深模块与测试判定等主题。