在测试方法开头编写assertNotNull(mockObject)是否合理？何时需校验Mock对象非空？

一、测试方法开头编写assertNotNull(mockObject)的合理性 #

正常使用@Mock注解配合MockitoExtension这类扩展时，Mock对象会在测试方法执行前被Mockito自动完成初始化。这种场景下，编写assertNotNull(mockObject)几乎没有实际价值：

• 若Mockito初始化逻辑正常工作，Mock对象必然非空，这个断言只是验证了框架本身的正确性，和你要测试的业务逻辑无关；
• 若初始化失败（比如漏加扩展注解、注解使用错误），测试类在实例化阶段就会报错，根本轮不到执行测试方法里的断言。

你测试中这个断言能通过，仅仅是确认了Mockito的初始化机制正常运行，对业务代码的测试没有帮助。

二、需要对Mockito Mock对象做非空校验的场景 #

只有当Mock对象的创建脱离了Mockito自动初始化的可靠流程时，非空校验才有意义，典型场景包括：

• 手动创建Mock的场景：如果Mock对象是通过Mockito.mock(SomeClass.class)手动创建，且创建逻辑被封装在工具方法或复杂流程中，非空校验可以确保工具方法没有因逻辑错误返回null。示例：

  @Test
  void testManualMock() {
      SomeClass mockObject = MockUtils.createMock(SomeClass.class);
      assertNotNull(mockObject); // 验证工具方法创建Mock成功
      // 后续业务测试逻辑
  }
  

• 多框架集成/自定义扩展场景：测试类同时集成多个框架扩展，或者使用了自定义测试扩展逻辑，可能干扰Mockito的注解初始化流程，此时非空校验可以快速定位Mock对象未正确初始化的问题。
• 动态生成Mock的复杂场景：通过反射、动态代理等方式动态生成Mock，或测试中根据条件动态创建Mock，这类场景下Mock创建存在失败风险，非空校验能提前暴露问题。

总结 #

常规注解式Mock初始化场景下，assertNotNull(mockObject)属于冗余代码，完全没必要编写；只有当Mock对象的创建逻辑脱离了Mockito自动初始化的可靠流程时，才需要添加这类校验来保障测试的前置条件。

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