用途：在构建功能或修复缺陷时，按测试驱动开发（TDD）的红-绿-重构循环推进，让测试先于实现。
主要理念：核心原则是测试通过公共接口验证行为，而非实现细节。代码可以完全改变，测试不应随之改变。好的测试是集成式风格，走真实代码路径，读起来像规格说明，描述系统做什么；坏的测试耦合实现，mock 内部协作对象、测试私有方法或通过外部手段验证，其警示信号是重构但行为未变时测试却失败。
反模式：不要先写全部测试再写全部实现，即“横向切片”。这会产出批量编写、测试想象行为的低质测试，只测数据结构和函数签名，对真实行为变化不敏感。正确做法是通过示踪弹的垂直切片：一个测试对应一个实现，反复进行。
工作流：一、规划。写代码前与用户确认接口变更、要测试的行为并排序，识别深模块机会，为可测试性设计接口，列出要测的行为而非实现步骤，获得用户批准。二、示踪弹。先写一个确认一件事的测试，红：测试失败；绿：写最小代码使其通过。三、增量循环。对每个剩余行为：红，写下一个测试并失败；绿，最小代码使其通过。规则：一次一个测试，只写足够通过当前测试的代码，不为未来测试提前设计，测试聚焦可观察行为。四、重构。全部测试通过后，寻找可提取重复、加深模块、应用 SOLID 原则的机会，每步重构后运行测试。绝不在红时重构。
每轮检查清单：测试描述行为而非实现；测试只使用公共接口；测试能在内部重构后存活；代码对当前测试而言是最小的；未添加投机性功能。
适用场景：需要在功能开发或缺陷修复中采用 TDD、提到红-绿-重构时使用。
限制：资料未提供具体平台、收费、价格或安装命令等信息；具体测试与 mock 示例见资料提到的 tests.md 与 mocking.md，本页未展开。