如何在不修改被测静态Java代码的情况下替换目标类？

这种直接硬编码new ExtClass()的情况确实头疼，尤其是不能改原代码的时候！别担心，有几个靠谱的方案能帮你实现Mock替代，不用动一行原代码：

方案一：使用PowerMock拦截构造函数调用 #

PowerMock是Mockito的扩展，它能通过修改字节码的方式拦截类的构造函数调用，直接返回你定义的Mock实例，完美适配你这种不能改原代码的场景。

步骤说明： #

1. 引入依赖（以Maven为例）：

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>2.0.9</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito2</artifactId>
    <version>2.0.9</version>
    <scope>test</scope>
</dependency>

2. 编写测试类：

import org.junit.Test;
import org.junit.runner.RunWith;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;
import foo.ExtClass;

@RunWith(PowerMockRunner.class)
@PrepareForTest(App.class) // 告诉PowerMock需要修改App类的字节码来拦截构造函数
public class AppTest {

    @Test
    public void testMain() throws Exception {
        // 1. 创建ExtClass的Mock实例
        ExtClass mockExt = PowerMockito.mock(ExtClass.class);
        
        // 2. 拦截App类中所有new ExtClass()的调用，返回我们的Mock实例
        PowerMockito.whenNew(ExtClass.class).withAnyArguments().thenReturn(mockExt);
        
        // 3. 调用被测的main方法
        App.main(new String[]{});
        
        // 4. 验证Mock对象的方法是否按预期被调用（根据你的业务逻辑调整）
        PowerMockito.verify(mockExt).yourMethodToVerify();
    }
}

优缺点： #

• ✅ 优点：无需修改原代码，配置简单，能快速实现Mock替换
• ❌ 缺点：依赖字节码修改，可能和某些类加载器、框架（如JaCoCo代码覆盖率工具）存在兼容性问题

方案二：自定义字节码增强（进阶） #

如果PowerMock的兼容性不符合你的需求，还可以用ByteBuddy、ASM这类字节码操作工具，在类加载阶段直接替换ExtClass的实现，或者修改App类中构造函数的调用逻辑。

举个ByteBuddy的简单示例（替换ExtClass的实现）：

import net.bytebuddy.ByteBuddy;
import net.bytebuddy.dynamic.loading.ClassLoadingStrategy;
import net.bytebuddy.matcher.ElementMatchers;
import foo.ExtClass;

// 在测试启动时替换ExtClass
public class TestSetup {
    public static void setup() {
        new ByteBuddy()
            .subclass(ExtClass.class)
            .method(ElementMatchers.any())
            .intercept(net.bytebuddy.implementation.FixedValue.nullValue()) // 自定义Mock逻辑
            .make()
            .load(ExtClass.class.getClassLoader(), ClassLoadingStrategy.Default.INJECTION)
            .getLoaded();
    }
}

优缺点： #

• ✅ 优点：高度灵活，完全可控，能应对复杂场景
• ❌ 缺点：学习成本高，需要熟悉字节码操作，代码编写复杂度高

方案三：临时调整类路径（仅限简单场景） #

如果你的ExtClass是一个普通类，没有复杂的依赖，可以在测试时把自定义的Mock版ExtClass放到类路径的更优先级位置（比如测试资源的foo包下），让类加载器优先加载你的Mock类。

注意： #

这种方法只适用于ExtClass没有被其他类强依赖且逻辑简单的场景，一旦原ExtClass有复杂的继承或依赖关系，很容易出现类加载冲突。

内容的提问来源于stack exchange，提问作者Y.L