工程测试编写指南

要解决的问题

compound-eng-writing-tests 针对的是工程团队中常见的测试失焦：测试只验证调用、只测 happy path、大量 mock 内部对象、快照一更新就通过，导致生产仍出现 bug。资料把问题拆成三类：需求实现与响应声明之间的覆盖缺口、try/catch 等路径造成的静默失败，以及由 mock、测试专用方法、循环断言等形成的反模式。

技能如何工作

该技能给出可执行的测试编写流程：先按单一行为拆分用例，再从 user requirements、features implemented、claims in the response 三个来源枚举用例；强调 DAMP over DRY，允许测试中重复 setup 以换取可读性。对 API/Web 项目建议约 80% 单元、15% 集成、5% E2E，并按风险调整。它要求优先使用真实数据库、内部服务和临时目录，仅 mock 外部 API、支付、邮件等系统边界。修复 bug 时采用 fail -> fix -> pass 的 prove-it 流程；新功能则要求边实现边测试。

适用边界与注意点

该技能更适合作为工程师评审测试、补测和 code review 的检查清单，而不是直接生成业务测试代码。它对 AI 生成测试的常见坏味道尤其敏感，例如 mock 被测对象、expect(sum(a,b)).toBe(a+b)、没有断言的调用、过度宽松匹配。落地时仍需结合项目测试框架、数据库隔离策略和 CI 环境，避免把测试基础设施状态污染误判为逻辑 bug。