用途：在构建功能或修复缺陷时采用测试驱动开发，遵循红-绿-重构循环。
核心理念：测试应通过公共接口验证行为，而非实现细节。好的测试是集成风格，走真实代码路径，读起来像规格说明（如“用户可用有效购物车结账”），能经受重构。坏的测试耦合实现，mock 内部协作者、测私有方法或绕过接口直接查数据库；若重命名内部函数就导致测试失败，说明测的是实现而非行为。
反模式：横向切片。不要先写完所有测试再写所有实现。应使用垂直切片与曳光弹：一个测试→一个实现→重复，每个测试回应上一轮学到的内容。
工作流：1）规划：探索代码库时使用项目领域词汇表，遵守相关 ADR；写代码前与用户确认接口变更、要测试的行为（排优先级）、识别深模块机会、为可测试性设计接口、列出行为清单并获批准。2）曳光弹：写一个测试确认一件事，RED 失败，GREEN 写最小代码通过。3）增量循环：对每个剩余行为，一次一个测试，只写足够通过当前测试的代码，不预判未来测试。4）重构：全部通过后提取重复、深化模块、应用 SOLID，每步后运行测试；绝不在 RED 状态重构。
每轮检查清单：测试描述行为而非实现；只用公共接口；能经受内部重构；代码对当前测试最小；不添加投机功能。
限制：资料未提供具体安装命令、平台支持、收费信息或代码示例细节，相关文件（tests.md、mocking.md）内容暂未提供。