JUnit5中@ExtendWith(MockitoExtension.class)对比mock()的劣势分析

首先，切换到@ExtendWith(MockitoExtension.class)搭配@Mock注解的写法，核心优势就是减少样板代码，让测试类的结构更简洁，这是业界普遍认可的优化方向。针对你提到的担忧和其他需要考量的点，具体分析如下：

一、关于耦合问题 #

你提到测试代码已大量使用verify等Mockito方法，耦合本就很高，这个判断是准确的。使用MockitoExtension和@Mock注解，只是将Mock对象的初始化逻辑从手动代码转移到注解声明，并没有新增额外的强耦合——本质上还是依赖Mockito的核心能力。反而，注解式写法能让依赖关系更直观：字段上的@Mock一眼就能标明这是一个Mock对象，比隐藏在setup方法里的初始化代码可读性更强。

二、关于性能问题 #

个别测试显示注解式写法耗时是手动Mock的4倍，这种情况大概率是特定场景下的偶发现象，而非普遍情况：

• 可能是该测试类中Mock对象数量极多，Extension的批量初始化逻辑在单次测试中产生了额外开销；
• 也可能是测试环境的临时波动（比如JVM缓存、资源占用）导致的差异。

建议你跑整个测试套件做统计对比，而不是只看个别测试。大部分常规测试场景下，两种写法的性能差异可以忽略不计。如果确实存在批量测试的性能差距，可以考虑：

• 检查是否有不必要的Mock对象，精简测试依赖；
• 针对性能敏感的测试类，保留手动Mock的写法。

三、其他需要考量的因素 #

1. 初始化灵活性 #

手动在@BeforeEach的setup方法中Mock时，你可以灵活添加自定义逻辑：比如给Mock设置默认返回值、自定义Answer实现，甚至根据不同测试用例动态调整Mock的创建参数。而@Mock注解默认使用Mockito的规则创建对象，如果需要自定义，得配合注解参数（如@Mock(answer = Answers.RETURNS_SMART_NULLS)），或者把自定义逻辑移到@BeforeEach方法中补充配置。如果你的测试中有大量复杂的Mock初始化逻辑，切换后需要调整写法。

2. 团队协作与习惯 #

如果团队长期使用手动Mock的写法，切换到注解式需要成员适应新的编码风格。不过注解式写法的可读性更高，新成员接手时能快速识别Mock依赖，长期来看有助于降低维护成本。建议先在小范围测试类中试点，待团队适应后再全面推广。

3. 异常排查成本 #

手动Mock的初始化逻辑完全在自己的代码中，出问题时可以直接在setup方法里加断点调试；而MockitoExtension的初始化是由框架完成的，若出现Mock初始化失败的情况，排查时需要了解Extension的执行流程（比如JUnit5的扩展生命周期）。不过这种情况非常少见，大部分时候注解式初始化的稳定性更高。

4. 多Extension兼容性 #

如果你的测试类还使用了其他JUnit5 Extension（比如SpringExtension），需要确保MockitoExtension与它们兼容。好在Mockito官方已经做了充分的兼容处理，比如Spring Boot的@SpringBootTest已经集成了Mockito的支持，无需额外配置。但如果是自定义Extension，需要测试两者的执行顺序和逻辑是否冲突。

5. 测试隔离性 #

MockitoExtension会在每个测试方法执行前重新初始化所有@Mock标注的对象，确保测试用例之间的隔离性，这和手动在@BeforeEach中初始化的效果完全一致，所以无需担心隔离性问题。但如果你的setup方法中有特殊的共享逻辑（比如全局Mock的配置），切换后需要确保这些逻辑能正确融入Extension的初始化流程。

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