Mockito：验证Mock调用内部的Mock方法调用异常问题

我明白你现在遇到的困境：你已经创建了Model的Mock类，想要验证另一个DAO Mock对象是否正确调用了Model的方法，但实际测试时发现这个调用并没有触发在Model类上，只能在DAO类层面完成验证。结合你提到的DAO方法、测试错误和Barrier类的场景，我给你几个可行的解决思路：

1. 确认DAO与Model的依赖注入是否正确 #

• 一定要确保你的DAO Mock对象依赖的是你创建的那个Model Mock实例，而不是在内部意外初始化了新的Model对象。可以通过测试初始化阶段显式注入的方式来锁定依赖：

  // 示例（以Mockito框架为例）
  ModelMock modelMock = Mockito.mock(ModelMock.class);
  DAOMock daoMock = new DAOMock(modelMock); // 显式将Model Mock注入DAO
  

2. 先验证DAO内部对Model的调用逻辑 #

• 先拆解问题，先确认DAO方法里是否真的正确调用了Model的目标方法。比如你的DAO方法如果是这样：

  public void processData() {
      // 这里是否确实调用了Model的方法？
      model.handleData();
  }
  

• 可以先在DAO的单元测试中直接验证Model Mock的调用情况：

  @Test
  public void testProcessData() {
      // 准备Mock实例
      ModelMock modelMock = Mockito.mock(ModelMock.class);
      DAOMock daoMock = new DAOMock(modelMock);
      
      // 执行DAO方法
      daoMock.processData();
      
      // 验证Model方法是否被调用
      Mockito.verify(modelMock, Mockito.times(1)).handleData();
  }
  

• 如果这个验证通过，说明DAO内部确实正确调用了Model；如果不通过，那问题根源在DAO的逻辑实现上，需要修正DAO对Model的调用代码。

3. 排查Barrier类对调用链的影响 #

• 你提到了Barrier类，需要重点检查它是否在DAO和Model的调用链路中做了拦截、异步处理或者实例替换操作：
  • 如果Barrier涉及异步逻辑，必须在测试中等待异步任务执行完毕后再做验证，比如调用barrier.await()确保所有异步流程完成；
  • 检查Barrier是否替换了原本注入的Model Mock实例，或者改变了调用路径，导致Model的方法调用没有被Mock捕获。

4. 确认Mock框架的使用是否规范 #

• 如果你使用Mockito、PowerMock这类框架，要确保Model Mock的创建方式正确：
  • 避免误用spy替代mock（spy会保留原类的部分实际逻辑，可能导致Mock行为失效）；
  • 检查测试代码中是否有其他地方重置了Mock对象，导致验证时丢失调用记录。

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