用途
该技能面向编写或修改测试、添加 mock、或考虑加入仅测试用钩子的场景，用于防止常见测试反模式。其核心主张是：测试必须验证真实行为，而不是 mock 行为；mock 是隔离工具，永远不是被测对象。
主要能力
技能以“铁律”和“反模式”两条线索组织内容。
铁律包括：
- 绝不测试 mock 行为；
- 绝不向生产类添加仅测试用的方法；
- 绝不在不理解依赖的情况下 mock；
- 绝不交付不完整的 mock；
- 绝不把集成测试当作事后补充。
反模式部分逐条给出错误示例、错误原因、修复方式和判断门槛：
- 反模式 1：测试 mock 行为。错误示例是在 mock
<Sidebar/>后断言getByTestId('sidebar-mock')存在。问题在于这只证明 mock 可用，对组件本身没有任何说明。修复方式是测试真实组件，或仅为隔离而 mock，但断言行为而非 mock 内部。门槛：在断言 mock 前先问“我是在测试真实行为还是只测试 mock？”如果是 mock，就删除断言或取消 mock。 - 反模式 2：生产代码中的仅测试方法。错误示例是添加只在测试中使用的
Session.destroy()。问题在于污染生产 API，若被线上调用会很危险。修复方式是把清理辅助方法移到测试工具中，生产类只暴露真实生命周期。门槛：添加方法前问“这是否只用于测试？”以及“这个类是否拥有该生命周期？”若前者为“是”或后者为“否”，就停止。 - 反模式 3：不理解就 mock。错误示例是 mock 一个同时会写配置的高层方法，导致重复检测失败。修复方式是只 mock 缓慢或外部部分（例如服务器启动），保留必要的副作用。门槛：mock 前回答：真实方法有哪些副作用？测试是否依赖它们？我是否完全理解依赖链？若不确定，先用真实实现运行、观察，再做最小化 mock。
- 反模式 4：不完整的 mock。错误示例是 mock 响应只包含用到的字段，而下游需要
metadata.requestId。修复方式是镜像完整的真实 schema（status、data、metadata 等）。门槛：查看真实 API 或文档，包含消费者可能触及的每个字段；若不确定，复制完整结构。 - 反模式 5：把集成测试当作事后补充。错误示例是“实现完成”却没有测试。修复方式是遵循 TDD：先写失败测试，再实现，后重构。
技能还提醒：如果 mock 设置比测试逻辑还复杂，应重新考虑是否需要 mock；使用真实组件的集成测试可能更简单。TDD 可以防止这些问题：先失败确保测试验证真实行为，防止仅测试用的生产代码，并揭示 mock 何时不必要。
使用方式
在编写或修改测试、添加 mock、或考虑加入仅测试用钩子时应用该技能。按反模式条目中的“门槛”问题自查，并参考快速参考表：断言 mock 时改为测试真实行为或取消 mock；仅测试方法移到测试工具；盲目 mock 先理解依赖；部分 mock 匹配真实 API schema；没有测试则走 TDD 循环。
适用场景
适用于单元测试、集成测试、mock 设计、测试与生产代码边界划分，以及采用 TDD 工作流的开发过程。
限制
资料未提供该技能的具体安装命令、支持平台、收费方式或效果数据，这些信息暂未提供。