用途：以测试驱动开发（TDD）方式构建功能或修复缺陷，遵循红-绿-重构循环，适用于用户提到此类需求时。
核心理念：测试应通过公共接口验证行为，而非实现细节；代码可以整体重写，测试不应随之改变。优质测试为集成风格，真实走通公共API的代码路径，像规格说明一样描述系统“做什么”，而非“怎么做”，因而能在重构后存活。劣质测试耦合实现，例如模拟内部协作者、测试私有方法或用外部手段校验；典型信号是重构后行为未变但测试失败。
反模式：横向切片，即先集中写完全部测试再写全部实现。这会产出劣质测试：批量测试的是想象的行为而非真实行为；测的是数据结构、函数签名等形态而非面向用户的行为；对真实变化不敏感；在尚未理解实现前就锁定测试结构。正确做法是纵向切片（曳光弹）：一个测试对一个实现，循环推进。
工作流：1）规划，先探索代码库，使用项目领域术语表让测试命名与接口词汇匹配项目语言，遵守相关ADR；与用户确认需要哪些接口变更、优先测试哪些行为，识别深模块机会，设计可测试接口，列出要测试的行为而非实现步骤，并获得用户对计划的批准。2）曳光弹：写一个只确认一件事的测试，红为失败，绿为最小实现通过，证明路径端到端可用。3）增量循环：对每个剩余行为重复“红写测试失败，绿写最小代码通过”；一次一个测试，只写够当前测试通过的代码，不为未来测试预判，测试聚焦可观察行为。4）重构：全部测试通过后提取重复、深化模块、在自然之处应用SOLID、思考新代码揭示的旧代码问题，每步重构后运行测试；切勿在红色状态重构，先到绿色。
每循环检查清单：测试描述行为而非实现；仅使用公共接口；能经受内部重构；代码对本测试最小化；不添加投机性功能。
限制与缺失：资料未提供收费、价格、平台支持、安装命令等细节，暂未提供；参考资料中提及tests.md与mocking.md，但未给出其内容。