MockitoAnnotations.openMocks(this) 替代方案有哪些？

Question

**常见技术问题：** 在 Mockito 4.11+ 版本中，`MockitoAnnotations.openMocks(this)` 已被标记为过时（@Deprecated），并在 Mockito 5 中彻底移除。开发者升级后常遇 `NoSuchMethodError` 或编译失败，尤其在使用 `@Mock`、`@InjectMocks` 等注解但未显式初始化 mock 的测试类中。根本原因在于 Mockito 放弃了基于反射的手动初始化模式，转向更安全、更明确的依赖注入机制。典型场景包括：JUnit 4/5 测试类中仍沿用旧式 `@Before` + `openMocks()`；或误以为 `@ExtendWith(MockitoExtension.class)` 与 `openMocks()` 可共存。该问题不仅影响代码可维护性，还可能导致 mock 未正确创建、`NullPointerException` 难以排查。亟需了解现代、官方推荐的替代方案及其适用边界。

Answer 1

```html

一、现象层：过时 API 引发的典型故障表征

• MockitoAnnotations.openMocks(this) 在 Mockito 4.11+ 中被 @Deprecated 标记，编译期警告频现；
• 升级至 Mockito 5 后直接抛出 NoSuchMethodError: MockitoAnnotations.openMocks，构建失败；
• JUnit 4 中仍保留 @Before public void init() { openMocks(this); } 导致 mock 字段为 null；
• JUnit 5 下混用 @ExtendWith(MockitoExtension.class) 与手动 openMocks()，触发重复初始化异常（MockitoException: Mock already initialized）；
• @InjectMocks 对象字段未注入，调用时抛 NullPointerException，堆栈无明确线索。

二、机制层：为何弃用？——从反射黑盒到契约化生命周期管理

Mockito 早期依赖 ReflectionUtils 在运行时暴力设置 @Mock 字段可见性并实例化，存在三大本质缺陷：

问题维度	旧模式风险	新模型保障
安全性	绕过封装，破坏 final/static/私有语义	仅支持标准字段注入，拒绝非法访问
可预测性	初始化时机模糊（@Before vs @Test），易受执行顺序干扰	由 JUnit Extension 显式控制生命周期（beforeEach → afterEach）
诊断能力	mock 失败无上下文（如字段名、类型、注解位置）	抛出带完整元数据的 MockitoConfigurationException

三、解决方案层：官方推荐路径全景图

1. JUnit 5（首选）：声明式启用 @ExtendWith(MockitoExtension.class)，自动处理全部注解生命周期；
2. JUnit 4 兼容方案：使用 @RunWith(MockitoJUnitRunner.class)（注意：该 runner 在 Mockito 5 中已移除，仅适用于 4.x 迁移过渡期）；
3. 无框架纯 Java 方式：改用构造器/Setter 注入 + 手动 new Mock（适用于单元测试隔离度要求极高场景）；
4. Spring Boot 测试：结合 @SpringBootTest + @MockBean，交由 Spring Context 管理 mock 生命周期。

四、实践验证：迁移前后对比代码示例

// ❌ 过时写法（Mockito 4.11+ 编译警告，Mockito 5 报错）
public class LegacyServiceTest {
    @Mock private UserRepository userRepository;
    @Mock private EmailService emailService;
    @InjectMocks private UserService userService;

    @Before
    public void setUp() {
        MockitoAnnotations.openMocks(this); // ← 已废弃！
    }

    @Test
    public void shouldSendWelcomeEmailOnUserCreation() {
        when(userRepository.save(any())).thenReturn(new User(1L, "test"));
        userService.createUser("[e-mail]");
        verify(emailService).sendWelcomeEmail("[e-mail]");
    }
}

// ✅ 现代写法（JUnit 5 + MockitoExtension）
@ExtendWith(MockitoExtension.class)
class ModernServiceTest {
    @Mock private UserRepository userRepository;
    @Mock private EmailService emailService;
    @InjectMocks private UserService userService; // 自动注入，无需 openMocks()

    @Test
    void shouldSendWelcomeEmailOnUserCreation() {
        when(userRepository.save(any())).thenReturn(new User(1L, "test"));
        userService.createUser("[e-mail]");
        verify(emailService).sendWelcomeEmail("[e-mail]");
    }
}

五、边界与陷阱：高级场景适配指南

graph TD
    A[测试类结构] --> B{是否含 @Nested 内部类？}
    B -->|是| C[需为每个 @Nested 显式添加 @ExtendWith]
    B -->|否| D[顶层类单次声明即可]
    A --> E{是否混合使用 @Spy 和 @Mock？}
    E -->|是| F[确保 @Spy 字段非 final，且构造器可访问]
    E -->|否| G[标准流程适用]
    A --> H{是否需自定义 mock 行为？}
    H -->|是| I[使用 @Mock(answer = Answers.CALLS_REAL_METHODS) 或 @Spy]
    H -->|否| J[默认 STRICT_STUBS 模式更安全]

六、演进趋势：Mockito 5+ 的架构级重构信号

• 彻底移除 MockitoAnnotations 工具类，强制推行 Extension 驱动模型；
• 引入 MockitoSession（低阶 API），供框架集成方（如 TestNG 支持库）实现定制化生命周期；
• @Mock 默认启用 STRICT_STUBS，未 stub 的调用直接抛异常，杜绝隐式返回 null/0/false；
• 与 JUnit Platform 的 TestInstanceFactory 深度协同，支持 per-test-instance mock 隔离；
• 未来版本将强化对 Kotlin data class、record 类型的原生支持，进一步收窄反射滥用面。

```