本文探讨java单元测试中，如何解决私有方法内部通过new关键字创建的复杂对象难以mock的问题。我们将阐述传统mocking方式的局限性，并详细介绍如何引入可注入的工厂模式作为解决方案，从而提高代码的可测试性、解耦性，并提供具体的代码示例和测试方法。
私有方法内部创建对象带来的测试挑战
在Java单元测试中，我们经常会遇到这样的场景：一个公共方法（publicMethod）内部调用了一个私有方法（privateMethod），而这个私有方法又直接使用new关键字实例化了一个复杂的依赖对象（ObjectNeeded2Mock）。当我们需要测试publicMethod时，如何控制或替换privateMethod中创建的ObjectNeeded2Mock实例，就成了一个棘手的问题。
传统的Mocking框架（如Mockito）主要通过代理或字节码修改来模拟对象的行为，但它们通常无法直接干预方法内部局部变量的创建过程，也无法直接对私有方法进行Mocking（这通常也不被视为良好的测试实践，因为单元测试应关注公共接口）。
考虑以下示例代码结构：
// 假设 ObjectNeeded2Mock 是一个需要被Mock的复杂依赖
public class ObjectNeeded2Mock {
private String config;
public ObjectNeeded2Mock(String config) {
this.config = config;
}
public String doSomething() {
return "Result from " + config;
}
}
public class ParentClass {
public ParentClass() {
// 构造器可能还有其他初始化
}
public String publicMethod(String... arguments) {
// ... publicMethod 的一些逻辑 ...
ObjectNeeded2Mock obj1 = privateMethod(arguments[0]); // 调用私有方法
return "Processed: " + obj1.doSomething();
}
private ObjectNeeded2Mock privateMethod(String argument) {
// 问题所在：直接在这里创建对象，难以在外部控制
ObjectNeeded2Mock obj = new ObjectNeeded2Mock("internal_config_" + argument);
// ... privateMethod 的进一步初始化或操作 ...
return obj;
}
}在这种情况下，即使我们使用@Mock注解来模拟ObjectNeeded2Mock，并尝试用@InjectMocks将ParentClass注入，Mock对象也无法替换privateMethod中通过new关键字创建的实际对象。这是因为@InjectMocks通常用于注入成员变量，而不是改变方法内部的局部变量创建行为。
立即学习“Java免费学习笔记（深入）”；
解决方案：引入可注入的工厂模式
解决上述问题的核心思想是：将对象的创建职责从具体的实现类中剥离出来，委托给一个外部可控的“工厂”对象。这个工厂对象可以作为依赖注入到ParentClass中，从而在测试时被Mock，进而控制ObjectNeeded2Mock的实例。
1. 定义工厂接口
首先，我们需要定义一个工厂接口，用于抽象ObjectNeeded2Mock的创建过程：
public interface ObjectFactory {
ObjectNeeded2Mock createObject(String config);
}2. 实现默认工厂
提供一个默认的工厂实现，用于生产环境：
public class DefaultObjectFactory implements ObjectFactory {
@Override
public ObjectNeeded2Mock createObject(String config) {
return new ObjectNeeded2Mock(config);
}
}3. 重构 ParentClass
修改ParentClass，使其通过构造器注入ObjectFactory，并在私有方法中使用工厂来创建ObjectNeeded2Mock实例：
public class ParentClass {
private final ObjectFactory objectFactory; // 注入工厂接口
// 通过构造器注入工厂依赖
public ParentClass(ObjectFactory objectFactory) {
this.objectFactory = objectFactory;
}
public String publicMethod(String... arguments) {
// ... publicMethod 的一些逻辑 ...
ObjectNeeded2Mock obj1 = privateMethod(arguments[0]);
return "Processed: " + obj1.doSomething();
}
private ObjectNeeded2Mock privateMethod(String argument) {
// 通过工厂创建对象，而不是直接 new
return objectFactory.createObject("internal_config_" + argument);
}
}现在，ParentClass不再直接依赖于ObjectNeeded2Mock的具体实现，而是依赖于ObjectFactory接口。这符合“依赖倒置原则”，极大地提高了代码的灵活性和可测试性。
单元测试示例
重构后，我们就可以在单元测试中Mock ObjectFactory，从而控制ObjectNeeded2Mock的实例。
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.ArgumentMatchers.anyString;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.verify; // 用于验证方法调用
public class ParentClassTest {
@Mock
private ObjectFactory mockObjectFactory; // Mock 工厂接口
@Mock
private ObjectNeeded2Mock mockObjectNeeded2Mock; // Mock 需要被工厂创建的对象
@InjectMocks
private ParentClass parentClass; // 注入被测试类，Mockito 会尝试将 mockObjectFactory 注入到 parentClass 的构造器中
@BeforeEach
void setUp() {
MockitoAnnotations.openMocks(this); // 初始化 Mock 对象
}
@Test
void testPublicMethodWhenPrivateMethodCreatesObject() {
// 1. 定义当 mockObjectFactory 的 createObject 方法被调用时，返回我们 Mock 的 ObjectNeeded2Mock
// 这里的 anyString() 表示无论传入什么字符串参数，都返回 mockObjectNeeded2Mock
when(mockObjectFactory.createObject(anyString())).thenReturn(mockObjectNeeded2Mock);
// 2. 定义我们 Mock 的 ObjectNeeded2Mock 的行为
when(mockObjectNeeded2Mock.doSomething()).thenReturn("Mocked Result from ObjectNeeded2Mock");
// 3. 调用被测试的公共方法
String result = parentClass.publicMethod("testArgument");
// 4. 验证结果是否符合预期
assertEquals("Processed: Mocked Result from ObjectNeeded2Mock", result);
// 5. （可选）验证工厂的 createObject 方法是否被调用，以及传入的参数是否正确
// 这里假设 privateMethod 会传入 "internal_config_testArgument"
verify(mockObjectFactory).createObject("internal_config_testArgument");
verify(mockObjectNeeded2Mock).doSomething(); // 验证 mockObjectNeeded2Mock 的 doSomething 方法是否被调用
}
}通过这种方式，我们成功地隔离了ParentClass对ObjectNeeded2Mock的直接依赖，使得在单元测试中能够完全控制其行为，而无需修改私有方法或依赖具体的ObjectNeeded2Mock实现。
注意事项与最佳实践
- 关注公共API测试： 单元测试的核心目标是验证类的公共接口行为。引入工厂模式是为了更好地控制公共接口所依赖的外部协作对象，而不是为了直接测试私有方法。私有方法通常通过其公共方法的行为间接得到测试。
- 依赖注入框架： 在大型Java项目中，Spring、Guice等成熟的依赖注入（DI）框架可以自动化工厂的创建、管理和注入过程，进一步简化代码并减少样板代码。在这种情况下，你通常会注入ObjectFactory的实现，而不是直接在ParentClass的构造器中手动创建它。
- 设计原则： 引入工厂模式是遵循“依赖倒置原则”（Dependence Inversion Principle, DIP）和“开放/封闭原则”（Open/Closed Principle, OCP）的良好实践。它使得高层模块不依赖于低层模块的实现细节，而是依赖于抽象，从而提高了代码的灵活性、可扩展性和可维护性。
- 避免过度Mocking： 虽然工厂模式解决了特定问题，但仍需注意避免过度Mocking。如果一个类有太多的依赖需要Mock，可能意味着这个类的职责过于复杂，需要进一步重构。
- 替代方案（有限）： 某些高级Mocking工具（如PowerMock）可以通过修改字节码来Mock私有方法甚至构造函数。然而，这些工具通常会增加测试的复杂性、降低可读性，并可能引入潜在的兼容性问题，因此通常不被推荐作为首选方案。工厂模式是更“干净”、更符合设计原则的解决方案。
总结
当Java私有方法内部直接通过new关键字创建复杂对象，导致单元测试难以Mock时，引入可注入的工厂模式是一种优雅而有效的解决方案。通过将对象的创建职责抽象到一个工厂接口，并将其作为依赖注入到被测试类中，我们可以在测试时轻松地Mock这个工厂，从而控制内部创建的依赖对象。这种方法不仅解决了测试难题，还提升了代码的可测试性、降低了模块间的耦合度，并促使代码设计更加符合面向对象的设计原则。
