用途：在开发功能或修复缺陷时，按测试驱动开发（TDD）流程推进，核心是红-绿-重构循环。资料说明其适用于用户想用 TDD 构建功能、修复缺陷，或提到 red-green-refactor 的场景。
核心原则：测试应通过公共接口验证行为，而不是实现细节；代码可以整体重写，测试不应因此失效。好的测试是集成式，走真实代码路径，读起来像规格说明，例如“user can checkout with valid cart”，能在内部重构后依然通过。坏的测试耦合实现，例如模拟内部协作者、测试私有方法，或绕过接口直接查数据库；典型信号是重构后行为未变但测试失败。资料提到可参考 tests.md 与 mocking.md。
反模式：不要先写完所有测试再写实现，即“水平切片”。问题在于批量测试的是想象行为而非实际行为，容易测数据结构或函数签名，测试对真实变化不敏感，还在理解实现前就锁定测试结构。正确做法是垂直切片、曳光弹：一个测试到一份实现，循环往复。
工作流：1）规划：先与用户确认接口变更、要测试的行为（按优先级）、识别深模块机会、设计接口可测试性、列出要测试的行为而非实现步骤，并获得用户批准；可询问“公共接口应该是什么样？哪些行为最重要？”2）曳光弹：写一个测试确认一件事，先红后绿，用最小代码通过，验证路径端到端可用。3）增量循环：对每个剩余行为，一次一个测试，仅写足够通过当前测试的代码，不预判未来测试，测试聚焦可观察行为。4）重构：全部测试通过后，寻找重构点，如提取重复、深化模块、在自然处应用 SOLID，并逐步运行测试；绝不在 RED 状态重构。
每轮检查清单：测试描述行为而非实现；只使用公共接口；能经受内部重构；代码对应当前测试保持最小；不添加推测性功能。
限制：资料未提供具体安装命令、平台支持、收费信息或与代码库的具体集成步骤，暂未提供。