用途：这是一个测试策略与设计技能，帮助判断代码该测什么、如何测，以及什么时候测试属于过度设计。核心目标是获得对代码的信心，而不是追求覆盖率数字。
主要原则：测行为而非实现，让测试能经受重构；测试金字塔是参考而非定律，具体形态取决于场景；快速反馈比完美覆盖率更有价值，因为测试慢就不会被运行；不稳定的测试比没有测试更糟，会让开发者习惯性忽略失败。
观点：TDD 强大但非普适，探索性代码、原型验证或 UI 场景下先写测试往往适得其反，边写边学阶段后补测试同样可行；100% 覆盖率常是浪费，配置、简单 getter、胶水代码通常不需要测试，应优先测有风险的部分；集成测试被低估，集成测试能捕获更多真实缺陷；Mock 被过度使用，若一个函数需要 10 个 mock 才能测试，说明其依赖过多。
使用方式：按要求将回答建立在给定参考资料上——创建时查阅 references/patterns.md 确定构建方式，诊断时查阅 references/sharp_edges.md 解释风险，评审时查阅 references/validations.md 校验输入；若用户请求与资料冲突应礼貌纠正。
不覆盖范围：调试测试失败、代码结构、重构、性能测试。
限制：资料未提供具体安装命令、平台支持或收费信息；实际可用性需以对应技能页面为准。