理解 Mockito 的 MockedStatic
mockedstatic 是 mockito 3.4.0 及以上版本引入的一项强大功能，它允许开发者在测试中模拟静态方法。这对于测试那些深度依赖静态方法的遗留代码或第三方库非常有用。通过 try-with-resources 语句，mockedstatic 确保了静态方法的模拟仅在特定测试范围内生效，避免了对其他测试的副作用。
遇到的问题：模拟 java.lang.Character 静态方法
在尝试使用 MockedStatic 模拟 java.lang.Character 类中的静态方法 isHighSurrogate 时，可能会遇到 Misplaced or misused argument matcher detected 错误，即使语法看起来正确。以下是一个典型的示例：
import org.junit.jupiter.api.Test;
import org.mockito.MockedStatic;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.ArgumentMatchers.anyChar;
class DummyClass {
public boolean filter(CharSequence source) {
// 假设这里依赖 Character.isHighSurrogate
// 实际应用中可能是其他更复杂的逻辑
return Character.isHighSurrogate(source.charAt(7));
}
}
public class DummyTest {
@Test
public void testDummyCharacterMockedStatic() {
try (MockedStatic mocked = Mockito.mockStatic(Character.class)) {
CharSequence source = "안녕하세요 세계";
// 尝试模拟 Character.isHighSurrogate(anyChar())
mocked.when(() -> Character.isHighSurrogate(anyChar())).thenReturn(true);
DummyClass d = new DummyClass();
assertTrue(d.filter(source));
}
}
} 运行上述测试时，可能会收到如下错误信息：
Misplaced or misused argument matcher detected here: -> at DummyTest.lambda$testDummyCharacterMockedStatic$0(DummyTest.java:XX) You cannot use argument matchers outside of verification or stubbing. Examples of correct usage of argument matchers: when(mock.get(anyInt())).thenReturn(null); ...
这个错误提示通常意味着 anyChar() 等参数匹配器在不被 Mockito 期望的地方被调用了。然而，在 mocked.when(() -> Character.isHighSurrogate(anyChar())) 这种 Stubbing 场景中，参数匹配器理应是合法的。那么，问题究竟出在哪里？
根本原因：避免模拟不拥有的类型
问题的核心在于 java.lang.Character 是 Java 标准库中的一个核心类。Mockito 官方强烈建议不要模拟你不拥有的类型（Do not mock types you don’t own），尤其是标准库中的类。
Mockito 的 MockedStatic 功能虽然强大，但它依赖于底层的字节码操作，这在处理 JVM 核心类时可能会遇到固有的限制和不确定性。Mockito 在其 mockStatic 的 JavaDoc 中明确指出：
注意：我们不建议模拟标准库中的类或自定义类加载器用于执行被模拟类的代码块中的静态方法。Mock Maker 可能会禁止模拟已知会引起问题的静态方法。此外，如果一个静态方法是 JVM 内置的（JVM-intrinsic），即使没有明确禁止，通常也无法模拟。
Character.isHighSurrogate 这样的方法可能被 JVM 视为内置方法（intrinsic），这意味着 JVM 可能会对其进行特殊优化，使其难以被 Mockito 的字节码修改技术所拦截和模拟。因此，即使参数匹配器在语法上正确，底层的 JVM 行为和 Mockito 的实现限制也可能导致这种“误用”的错误提示，实际上是无法成功模拟。
最佳实践与注意事项
避免模拟标准库类： 这是最重要的原则。标准库类通常经过了严格的测试，其行为是可靠和可预测的。在大多数情况下，你不需要模拟它们，而是应该信任它们的实际行为。如果你的代码逻辑依赖于这些类的特定行为，那么测试的重点应该是你的代码如何与这些真实行为交互，而不是去改变它们。
关注你自己的代码： 单元测试的核心目标是测试你编写的业务逻辑。如果你的代码依赖于第三方库或标准库，通常的做法是测试你的代码如何正确地调用这些外部依赖，以及如何处理它们返回的结果。
-
重构以提高可测试性： 如果你的代码与标准库的静态方法耦合过于紧密，导致难以测试，可以考虑重构。例如，将对静态方法的调用封装在一个你自己的接口实现中，然后模拟这个接口。
// 示例：将 Character.isHighSurrogate 封装到接口中 interface CharacterUtil { boolean isHighSurrogate(char ch); } class DefaultCharacterUtil implements CharacterUtil { @Override public boolean isHighSurrogate(char ch) { return Character.isHighSurrogate(ch); } } class DummyClassRefactored { private final CharacterUtil characterUtil; public DummyClassRefactored(CharacterUtil characterUtil) { this.characterUtil = characterUtil; } public boolean filter(CharSequence source) { return characterUtil.isHighSurrogate(source.charAt(7)); } } // 在测试中可以模拟 CharacterUtil 接口 // @Test // public void testDummyClassRefactored() { // CharacterUtil mockUtil = Mockito.mock(CharacterUtil.class); // Mockito.when(mockUtil.isHighSurrogate(anyChar())).thenReturn(true); // DummyClassRefactored d = new DummyClassRefactored(mockUtil); // assertTrue(d.filter("안녕하세요 세계")); // }这种方式将对 Character 类的直接依赖转化为对 CharacterUtil 接口的依赖，从而可以在测试中轻松模拟 CharacterUtil。
理解 MockedStatic 的局限性： MockedStatic 是一个强大的工具，但它并非万能。对于核心的 JVM 类、final 类、private 方法以及 equals()/hashCode() 等方法，模拟通常是不可行或不推荐的。
总结
MockedStatic 为 Mockito 带来了模拟静态方法的强大能力，但在使用时必须谨慎。尝试模拟 java.lang.Character 等标准库中的核心类，不仅可能遇到 Misplaced or misused argument matcher detected 这类令人困惑的错误，更重要的是违反了 Mockito 的最佳实践。为了编写健壮、可维护的测试，我们应该始终优先测试自己拥有的代码，并信任那些经过充分测试的外部依赖。当外部依赖导致测试困难时，优先考虑重构代码以提高可测试性，而不是强行模拟不应被模拟的类型。
