用途：该资料介绍测试驱动开发（TDD）的工作方法，适用于用户希望用 TDD 构建功能或修复缺陷、提到“red-green-refactor”的场景。
核心理念：测试应通过公共接口验证行为，而非实现细节。好的测试读起来像规格说明，能在重构后存活；坏的测试 mock 内部实现，行为未变却会失败。参考资料 tests.md 与 mocking.md。
反模式：反对“水平切片”，即先写完所有测试再写全部实现，这会产生检查想象形状而非真实行为的测试。正确做法是“垂直切片”配合曳光弹：一个测试、一个实现，循环往复。
工作流程分三阶段。一、规划：与用户确认接口变更及要测试的行为并排优先级；识别“深模块”即小接口、深实现；为可测试性设计接口；列出要测试的行为而非实现步骤并获得用户批准；聚焦关键路径与复杂逻辑。二、RED-GREEN 循环：先写一个端到端的曳光弹测试，然后针对每个行为重复——RED 写测试并使其失败，GREEN 写最少代码使其通过。一次只做一个测试，只写刚好通过的代码，不为未来测试预留。三、重构：所有测试通过后，提取重复、加深模块、自然处应用 SOLID，每步后运行测试。绝不在 RED 状态下重构。
每轮检查清单：测试描述行为而非实现；只使用公共接口；内部重构后测试仍能存活；代码对该测试是最少的；未添加投机性功能。
限制：资料未提供具体的编程语言、框架、安装命令或平台信息，相关内容暂未提供。