用途：在用户希望以测试先行的方式构建功能或修复缺陷、提到“红-绿-重构”或需要集成测试时使用。
主要能力与理念：核心原则是测试通过公共接口验证行为，而非实现细节。好的测试是集成式的，走真实代码路径、通过公共 API 描述系统做什么；测试应像规格说明，且能在重构后存活。坏测试耦合实现，如 mock 内部协作者、测私有方法或绕过接口直接查库；若重命名内部函数就导致测试失败，说明测的是实现。
应避免的反模式：横向切片，即先写全部测试再写全部实现，会产出批量想象行为的劣质测试，建议改为垂直切片（曳光弹），一次测试对应一次实现。同义反复测试，即断言用与代码相同方式重算期望值，测试必然通过；期望值须来自独立事实来源，如已知正确字面量、算例或规格。
工作流：0. 先发现技术栈，不假设 npm test，检查构建系统、仓库自带包装脚本（如 ./gradlew、./mvnw、make test），区分聚焦单测与全量套件命令，并参考 CI 工作流。1. 规划：阅读 CONTEXT.md 与 ADR，先写下并请用户确认待测接缝（公共边界），确认要测的行为并排序，列出行为而非实现步骤，获得用户批准。2. 曳光弹：写一个只确认一件事的测试，RED 失败后写最小实现使 GREEN 通过。3. 增量循环：每个剩余行为一次一个测试，仅写足够通过当前测试的代码，不预设未来测试。4. 重构：全部通过后消除重复、深化模块、应用 SOLID，每步后跑测试；RED 时绝不重构。每轮检查清单包括：测试描述行为而非实现、仅用公共接口、能经受内部重构、代码最小化、无投机功能。限制：未提供具体安装命令、平台、收费或价格信息，相关命令需按所在仓库实际约定确定。