严格桩是什么
严格桩（Strict Stubs）指测试替身框架的严格模式：未预先打桩的调用直接报错、打完却没用到的桩也报错，让测试与依赖对象的交互面保持精确。典型如 Mockito 的 StrictStubs 与 MockitoJUnitRunner 默认严格行为、Python unittest.mock 配合 spec 与 autospec 限制接口面。它把测试从静默漂移里拽出来——依赖改了口径，测试会立刻报警而不是照旧变绿。
基本信息
| 核心收益 | 暴露无用桩与未声明交互，测试随代码演进保持诚实 |
|---|---|
| 典型实现 | Mockito 的 strictness 配置、unittest.mock 的 autospec、spec_set |
| 严格行为 | 多余调用报错、未使用桩报错、参数不匹配视为失败 |
| 例外通道 | 确需宽松时按用例显式放宽，并写明理由 |
| 与脆弱测试区别 | 严格针对交互契约，避免的是静默漂移而非任何失败 |
| 配套实践 | 优先为必要交互打桩，减少过度模拟的测试 |
典型使用场景
- 长期维护的模块：接口缓慢演进时，无用桩能提示测试该更新了。
- 重构安全网：断言面收窄到真实交互，重构不用大改测试。
- 新项目默认开启：从一开始就养成精确打桩的习惯。
- 评审辅助：报错的未使用桩常暴露测试里的死代码。
- 多团队协作：第三方接口变更时报错即定位受影响测试。
严格与宽松模式取舍
| 维度 | 严格模式 | 宽松模式 |
|---|---|---|
| 多余桩 | 报错，提示清理 | 静默忽略 |
| 未声明调用 | 直接失败 | 放行返回默认值 |
| 维护成本 | 稍高，需随接口同步 | 低但隐患积累 |
| 适用场景 | 核心模块与长期项目 | 一次性验证或探索性测试 |
严格模式的目标是可信的绿灯：让通过意味着交互符合预期，而不是碰巧没被检查。
过度模拟是根问题：把被测对象切得太碎会造出大量脆弱桩，先审视设计再调严格度。
放宽要留痕：临时宽松处标注原因与期限，防止永久化。