用途：在编写或修改测试、添加 mock，或想在 production 代码中加入仅测试用方法时，用作自查指南，避免写出验证 mock 而非验证真实行为的测试。核心原则是：测试代码做了什么，而不是测试 mock 做了什么。
主要能力与铁律：该资料列出三条铁律：绝不测试 mock 行为；绝不向 production 类添加仅测试用方法；绝不理解依赖前就 mock。并覆盖五类反模式。一，测试 mock 行为：例如通过 testid 断言 sidebar-mock 存在，实际上只是在验证 mock 在工作；修复方式是测试真实组件或取消 mock，必要时只断言组件在 sidebar 存在时的行为。二，仅测试用方法进入 production：如仅为测试添加 destroy()，会污染生产类、可能被误调用，应把清理逻辑放入测试工具。三，不了解依赖就 mock：mock 可能抹掉测试所依赖的副作用，导致重复校验失效，应先确认副作用与测试依赖，再在更低层 mock 真正慢或外部的操作。四，不完整 mock：只 mock 自己知道的字段，会隐藏下游代码需要的结构，导致测试通过但集成失败，应按真实 API 完整镜像数据结构。五，把集成测试当作事后补充：测试属于实现的一部分，应与实现同步编写并验证后再宣布完成。
使用方式：资料给出 Gate Function 自查流程，例如断言 mock 元素前先问自己是在测真实组件还是测 mock 存在；在生产类加方法前先问是否只被测试使用；mock 前先弄清真实方法的副作用与测试依赖；创建 mock 响应前先检查真实 API 的完整字段；若不确定，先用真实实现跑测试观察实际需要，再进行最小 mock。另附快速参考表和红旗信号，如断言中出现 *-mock、方法只在测试文件被调用、mock 设置超过测试一半等。
适用场景与限制：适合使用 mock 进行隔离的前端或单元测试场景，尤其是集成测试与 mock 难易取舍的讨论。资料未提供具体安装命令、平台或价格信息，也未说明其运行环境。当 mock 过于复杂时，建议考虑使用真实组件的集成测试。该技能不替代具体测试框架的 API 文档。