用途
测试驱动开发（TDD）技能用于在实现任何功能或修复缺陷之前，先编写测试。其核心原则是：如果你没有亲眼看到测试失败，你就不知道它是否在测试正确的东西。违反规则的文字就是违反规则的精神。
主要能力
该技能提供了一套严格的 TDD 工作流程和纪律，包括：
- 铁律：没有失败的测试，就不写生产代码。如果先写了代码，必须删除并重新开始，不能保留作为“参考”，不能在写测试时“改编”它，也不能看它。删除就是删除。
- 红-绿-重构循环：
- RED：编写一个最小的失败测试，展示应该发生什么。要求：一个行为、清晰的名称、真实代码（除非不可避免，否则不用 mock）。
- 验证 RED：必须运行测试并亲眼看到它失败。确认测试失败（不是报错）、失败消息符合预期、失败原因是功能缺失（不是拼写错误）。如果测试通过，说明你在测试现有行为，需要修正测试；如果测试报错，修复错误并重新运行直到正确失败。
- GREEN：编写最简单的代码使测试通过。不要添加功能、重构其他代码或超出测试范围“改进”。
- 验证 GREEN：必须运行测试并亲眼看到它通过。确认测试通过、其他测试仍然通过、输出干净（无错误、警告）。如果测试失败，修复代码而不是测试；如果其他测试失败，立即修复。
- REFACTOR：仅在绿灯后进行。消除重复、改进名称、提取辅助函数。保持测试绿灯，不添加行为。
- 重复：为下一个功能编写下一个失败测试。
- 好测试的标准：最小（只做一件事，名称中有“and”就拆分）、清晰（名称描述行为）、展示意图（演示期望的 API）。
- 编写或修改任何测试时，需阅读 writing-good-tests.md 中的规则：在编写测试之前，说出会使测试失败的生产变更；断言真实行为，绝不断言 mock 行为；将仅用于测试的代码放在测试工具中，不要放在生产类中；在 mock 依赖之前，理解其副作用。
- 常见合理化借口与反驳：技能列出了大量借口及其现实反驳，例如“太简单不用测试”（简单代码也会出错，测试只需 30 秒）、“我之后测试”（之后写的测试立即通过，证明不了什么）、“已经手动测试过”（手动测试是临时的，无法记录覆盖范围，代码变更时无法重新运行）、“删除 X 小时很浪费”（沉没成本谬误）、“保留作为参考，先写测试”（你会改编它，那就是之后测试）、“需要先探索”（可以，丢弃探索，从 TDD 开始）、“测试难 = 设计不清晰”（听测试的，难测试 = 难使用）、“TDD 会拖慢我”（TDD 是务实之路）、“手动测试更快”（手动不能证明边缘情况）、“现有代码没有测试”（你在改进它，为现有代码添加测试）。
- 红旗信号：代码先于测试、实现后测试、测试立即通过、无法解释测试为何失败、测试“稍后”添加、合理化“就这一次”、“我已经手动测试过”、“之后测试达到相同目的”、“关于精神而非仪式”、“保留作为参考”或“改编现有代码”、“已经花了 X 小时，删除很浪费”、“TDD 是教条的，我很务实”、“这次不同因为……”。所有这些都意味着：删除代码，从 TDD 重新开始。
- 验证清单：在标记工作完成之前，每个新函数/方法都有测试；在实现之前亲眼看到每个测试失败；每个测试因预期原因失败（功能缺失，不是拼写错误）；编写最少代码使每个测试通过；所有测试通过；输出干净（无错误、警告）；测试使用真实代码（仅在不可避免时使用 mock）；覆盖边缘情况和错误。如果无法勾选所有框，说明你跳过了 TDD，需要重新开始。
- 卡住时的解决方案：不知道如何测试——写期望的 API，先写断言，询问人类伙伴；测试太复杂——设计太复杂，简化接口；必须 mock 一切——代码太耦合，使用依赖注入；测试设置巨大——提取辅助函数，仍然复杂？简化设计。
- 调试集成：发现缺陷？编写重现它的失败测试。遵循 TDD 循环。测试证明修复并防止回归。永远不要在没有测试的情况下修复缺陷。
使用方式
该技能以文档形式提供，包含具体的 TDD 规则、示例和检查清单。使用时，在实现任何功能或修复缺陷之前，遵循红-绿-重构循环，并严格遵守铁律。技能中提供了 TypeScript 测试示例（好与坏对比）、缺陷修复示例（空邮箱被接受）以及验证清单。
适用场景
始终适用于：新功能、缺陷修复、重构、行为变更。
例外情况（需询问人类伙伴）：一次性原型、生成代码、配置文件。
限制
该技能强调没有例外，除非获得人类伙伴的许可。它要求严格遵循规则，否则应删除代码并重新开始。技能本身不提供自动化工具，而是依赖开发者手动执行 TDD 流程。