在Mockito中是否推荐每个when调用都搭配对应的verify调用？

以下讨论仅针对你提到的「校验某mock方法以匹配参数被调用1次」的场景：

省略显式verify(times(1))、仅靠UnnecessaryStubbingException做校验的优劣势 #

• 优势
  • 代码更简洁，避免相同逻辑重复编写，单测开发效率更高
  • 不需要额外维护verify逻辑，只要stub不变，校验规则就不变
• 劣势
  • 测试意图模糊：其他维护者无法判断你写when stub是单纯为了支撑业务逻辑运行，还是要校验该方法必须被调用。如果后续业务逻辑调整，该方法的返回值不再是必选项，就算调用消失UnnecessaryStubbingException也不会触发，原有校验逻辑直接失效
  • 使用场景受限：如果被调用的方法是void类型，或者它的返回值完全不影响主逻辑运行，你为了触发UnnecessaryStubbingException的校验，需要强行写无意义的when stub，反而增加冗余代码
  • 不兼容verifyNoMoreInteractions：该方法会校验所有mock的交互都被显式验证过，就算目标方法确实被调用了，只要你没写verify，调用verifyNoMoreInteractions依然会抛出未验证交互的异常
  • 受框架配置影响大：UnnecessaryStubbingException是Mockito严格模式下的特性，一旦有人将测试类的strictness调整为LENIENT，该校验会直接失效，测试完全失去对应校验能力

保留显式verify(times(1))的优劣势 #

• 优势
  • 测试意图清晰：完全符合setup>execute>verify的通用测试范式，任何维护者看代码都能立刻明白，该用例的校验点包含「目标方法被调用1次」的要求，可维护性更高
  • 适用场景更广：不管目标方法有没有返回值、返回值是否影响主逻辑，都可以直接用verify做校验，不需要强行写冗余的stub
  • 兼容verifyNoMoreInteractions的使用，不会出现误报问题
  • 稳定性高：校验逻辑不受Mockito严格度配置的影响，不管全局/单测类的配置怎么改，校验规则都不会失效
  • 扩展性好：后续如果需要调整校验规则（比如修改调用次数、增加参数校验逻辑），直接修改verify语句即可，改动成本极低
• 劣势
  • 简单场景下会多一行校验代码，看起来略有冗余

通用推荐方案 #

工业界主流最佳实践更推荐保留显式verify调用。毕竟测试代码大部分时间是用来给人读的，明确的校验意图比少写一行代码的收益高得多，除非是极其简单、团队内部统一约定可以省略verify的场景，否则都建议显式写出校验逻辑。

内容的提问来源于stack exchange，提问作者oreid