用途：为采用“函数式核心／副作用边缘”架构的项目提供测试策略，指导 Stub 驱动的测试驱动开发以及在层边界处编写测试，而非测试内部实现细节。
主要能力：Stub 驱动 TDD 工作流，顺序为 Stub 建立最小接口签名、Test 针对桩编写测试、Implement 用真实实现让测试通过、Refactor 保持测试绿色；强调先写接口签名再测试再实现。分层边界测试给出各层的测试类型、需要打桩的对象与断言点：Entity 用单元测试、不打桩、断言校验与业务规则及转换；Service 用单元测试、打桩仓储、断言编排逻辑与错误处理；Router 用集成测试、打桩 Service、断言状态码与响应格式；Repository 用集成测试、打桩数据库连接、断言 CRUD 与查询；Consumer 用集成测试、打桩 Service、断言事件解析与服务调用。
使用方式：按依赖顺序自下而上推进——先写 Entity 测试（纯函数、快），再写 Service 测试（打桩依赖、快），最后写集成测试（真实 IO、较慢），以便先写低层测试再实现并向上构建。资料给出 Entity、Service、Router、Repository、Consumer 的示例代码片段，以及 references 目录下的进一步参考文件（stub-driven-tdd.md、boundaries.md、core-testing.md、edge-testing.md、anti-patterns.md）。
适用场景：需要在组件边界处确定测试位置、决定某段代码该不该测、为仓储与路由及事件消费者编写集成测试时。
限制与建议：追求策略性覆盖而非 100%。高覆盖重点为实体校验与业务规则、服务编排、关键用户旅程、带逻辑的数据转换；中等覆盖为错误路径、边界情况、API 契约校验；低覆盖为简单 getter/setter、框架样板、无逻辑映射、内部工具。不应测试私有方法（应通过公开 API 测试）、简单 getter/setter、框架行为、第三方库行为以及无逻辑的平凡映射。资料未提供安装命令或具体版本要求。