本文详解如何使用 mockito 4.11+（含 mockito-inline）在单元测试中安全地 mock 同一静态类内的其他静态方法（如 testable() 内部调用 something()），避免 null 返回、行为失效或 classcastexception 等常见陷阱。
本文详解如何使用 mockito 4.11+（含 mockito-inline）在单元测试中安全地 mock 同一静态类内的其他静态方法（如 testable() 内部调用 something()），避免 null 返回、行为失效或 classcastexception 等常见陷阱。
在 Java 单元测试中，当一个静态方法（如 testAble()）内部调用了同一类中的另一个静态方法（如 something()）时，传统 Mock 方式极易失败——因为默认情况下 mockStatic(MyClass.class) 会拦截该类所有静态调用，包括待测方法自身，导致 testAble() 返回 null 或抛出 NullPointerException。自 Mockito 3.4.0 起，通过 mockito-inline 模块支持静态方法 Mock；而从 Mockito 4.11+ 开始，该能力已稳定集成并大幅优化，关键在于正确使用 Answers.CALLS_REAL_METHODS 参数。
✅ 正确做法：使用 CALLS_REAL_METHODS 保留待测方法真实行为
CALLS_REAL_METHODS 是一个 Answer 策略，它确保：
- 被
mockStatic()包裹的类中，未显式 stub 的方法仍执行原始逻辑； - 仅对
when(...).thenReturn(...)显式定义的方法进行行为替换； - 完美适配“测试某静态方法 + Mock 其内部依赖的同类型静态方法”这一典型场景。
以下为完整可运行示例：
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Answers.CALLS_REAL_METHODS;
import static org.mockito.Mockito.mockStatic;
import org.junit.jupiter.api.Test;
import org.mockito.MockedStatic;
public class MyClassTest {
@Test
void testAble_returnsWow_whenSomethingReturnsHello() {
try (MockedStatic<MyClass> mocked = mockStatic(MyClass.class, CALLS_REAL_METHODS)) {
// 只 stub something()，testAble() 保持真实逻辑
mocked.when(MyClass::something).thenReturn("Hello");
String result = MyClass.testAble();
assertEquals("Wow", result);
}
}
@Test
void testAble_returnsLoL_whenSomethingReturnsNotHello() {
try (MockedStatic<MyClass> mocked = mockStatic(MyClass.class, CALLS_REAL_METHODS)) {
mocked.when(MyClass::something).thenReturn("not hello");
String result = MyClass.testAble();
assertEquals("LoL", result);
}
}
}? 关键点说明：
try-with-resources确保MockedStatic在测试结束时自动关闭，释放字节码增强资源；CALLS_REAL_METHODS必须显式传入（不可省略），否则MyClass.testAble()将被静默拦截并返回null；mocked.when(MyClass::something)使用方法引用语法，类型安全且推荐用于无参/有参静态方法；- 若
something()有参数（如something(int x)），可写为mocked.when(() -> MyClass.something(5)).thenReturn("custom")。
⚠️ 常见错误与规避方案
| 错误写法 | 问题 | 修复建议 |
|---|---|---|
mockStatic(MyClass.class)（无 CALLS_REAL_METHODS） |
testAble() 被拦截 → 返回 null → assertEquals 失败 |
必须传入 CALLS_REAL_METHODS |
mockStatic(MyClass.class, Answers.RETURNS_DEFAULTS) |
testAble() 返回 null（String 默认值） |
同上，RETURNS_DEFAULTS 不适用于待测目标方法 |
忘记 try-with-resources
|
静态 Mock 泄漏至后续测试 → 干扰其他用例 | 始终使用 try (var m = mockStatic(...)) { ... }
|
Maven 缺少 mockito-inline
|
mockStatic 方法不可用或抛 UnsupportedOperationException
|
确保 pom.xml 包含：<dependency><groupid>org.mockito</groupid><artifactid>mockito-inline</artifactid><version>5.12.0</version><scope>test</scope></dependency>
|
? 替代方案对比（何时考虑重构？）
虽然静态 Mock 可解燃眉之急，但长期维护建议优先考虑面向测试的设计重构：
-
✅ 推荐重构路径：将
MyClass改为普通类，提取something()为接口实现，通过构造器注入：public interface Provider { String something(); } public class MyClass { private final Provider provider; public MyClass(Provider provider) { this.provider = provider; } public String testAble() { return provider.something().equals("Hello") ? "Wow" : "LoL"; } }测试时直接
new MyClass(mock(Provider.class))—— 简洁、无字节码侵入、兼容所有 Mock 框架。 ⚠️ 慎用 PowerMock/JMockit：它们虽支持静态 Mock，但需字节码重写、JUnit 4 Runner、
@PrepareForTest等复杂配置，与现代 JUnit 5 + Mockito 原生方案相比，构建慢、调试难、易冲突。
✅ 总结
Mockito 原生静态 Mock 已成熟可靠，核心口诀是：mockStatic(Class, CALLS_REAL_METHODS) + try-with-resources + method reference stub。它让你无需引入重型框架，即可精准控制同类静态依赖的行为，同时保障待测方法逻辑完整执行。对于新项目，仍建议从设计层面规避静态耦合；而对于遗留系统，此方案是高效、轻量、可维护的首选实践。
