本文探讨了在java和mockito中，当被测试类内部实例化了依赖对象时，如何模拟该依赖对象方法返回值的挑战。我们将解释直接模拟的局限性，并提供一种通过引入依赖注入（如`supplier`）来重构代码以提升可测试性的解决方案。教程还将涵盖测试中模拟对象的最佳实践和注意事项。
理解问题：为何直接模拟失效？
在单元测试中，我们经常需要模拟（mock）依赖对象的行为，以隔离被测试单元。然而，当依赖对象在被测试类内部被实例化时，传统的Mockito模拟方法会失效。考虑以下示例代码：
class A {
public String foo() {
return "Real A's foo";
}
}
class B {
public A foo() {
return new A(); // B的foo方法内部创建并返回A的实例
}
}
class SomeClass {
public void doSomeThing() {
B b = new B(); // SomeClass内部创建B的实例
A a = b.foo();
System.out.println(a.foo());
}
}在这种结构中，SomeClass直接在doSomeThing方法内部创建了B的实例，而B的foo方法又内部创建了A的实例。当尝试对SomeClass进行测试时，我们可能会尝试以下方式来模拟A的行为：
import org.junit.jupiter.api.Test;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Mock
A aMock; // 尝试模拟A
@InjectMocks
SomeClass someClass;
@Test
void testDoSomeThing() {
// 期望aMock的foo方法返回特定值，但这种模拟不会生效
Mockito.when(aMock.foo()).thenReturn("Mocked A's foo");
// 执行doSomeThing方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 实际上，doSomeThing内部创建的是真实的A和B，aMock并未被使用
}
}上述测试尝试通过@Mock A aMock来模拟A，但这种方式是无效的。原因在于，SomeClass内部通过new B()创建了一个真实的B对象，进而B的foo()方法也返回了一个真实的A对象。Mockito无法拦截或替换这些在被测试类内部通过new关键字创建的实例。SomeClass与B之间，以及B与A之间，存在紧密的耦合，它们依赖于具体的实现而非抽象。
解决方案：重构代码以提升可测试性
要解决这个问题，核心思想是解耦：将被测试类内部创建依赖对象的职责转移出去，使其能够通过外部注入的方式获得依赖。这通常通过依赖注入（Dependency Injection, DI）模式实现。
我们可以通过引入一个工厂或Supplier接口来提供B的实例，而不是在SomeClass内部直接创建它。这样，在测试时，我们就可以注入一个提供模拟B对象的Supplier。
重构后的SomeClass
import java.util.function.Supplier;
class SomeClass {
// 使用Supplier来延迟和抽象B的创建
private final Supplier bFactory;
// 推荐的构造函数：通过Supplier注入B的创建逻辑
public SomeClass(final Supplier bFactory) {
this.bFactory = bFactory;
}
// 可选的无参构造函数，用于兼容旧代码或简化生产环境的实例化
// 在实际项目中，也应尽量通过DI框架管理依赖，避免手动new SomeClass()
public SomeClass() {
this(B::new); // 默认使用B的真实构造函数
}
public void doSomeThing() {
B b = this.bFactory.get(); // 从工厂获取B的实例
A a = b.foo();
System.out.println(a.foo());
}
}在这个重构后的SomeClass中：
- 我们引入了一个Supplier extends B> bFactory字段。Supplier是一个函数式接口，其get()方法不接受参数并返回一个结果。
- SomeClass的构造函数现在接受一个Supplier，允许外部控制B的实例化方式。
- doSomeThing方法通过this.bFactory.get()来获取B的实例，而不是直接new B()。
- 提供一个无参构造函数是为了方便迁移或在非测试环境下使用，它默认使用B::new（一个方法引用，等同于() -> new B()）作为Supplier。
编写可测试的代码：Mocking实践
现在，有了重构后的SomeClass，我们就可以在测试中轻松地注入模拟的B实例，进而控制A的返回行为。
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
class SomeClassTest {
@Test
void testDoSomeThingWithMocks() {
// 1. 模拟A对象
final A aMock = mock(A.class);
// 配置aMock的行为，例如当调用aMock.foo()时返回特定值
when(aMock.foo()).thenReturn("Mocked A's foo from test");
// 2. 模拟B对象
final B bMock = mock(B.class);
// 配置bMock的foo()方法，使其返回我们模拟的aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建一个Supplier，使其在调用get()时返回bMock
// 这样，当SomeClass请求B的实例时，会得到我们的bMock
final SomeClass someClass = new SomeClass(() -> bMock);
// 4. 执行被测试方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 验证bMock的foo方法是否被调用
Mockito.verify(bMock).foo();
// 验证aMock的foo方法是否被调用
Mockito.verify(aMock).foo();
}
}通过这种方式，我们成功地控制了SomeClass内部对B和A的依赖，使得测试可以完全隔离并验证SomeClass自身的逻辑。
注意事项与最佳实践
警惕“Mock返回Mock”的模式
尽管上述解决方案能够实现对内部实例化对象的模拟，但测试中出现“Mock返回Mock”（即when(bMock.foo()).thenReturn(aMock)）的模式通常被认为是不良实践。
- 测试脆弱性：这种测试过度耦合到被测试单元的实现细节。如果B.foo()返回的对象类型或其行为在未来发生变化，即使SomeClass的逻辑没有改变，测试也可能失败。
- 复杂性增加：测试代码变得更复杂，难以理解和维护。
- 违反单元测试原则：单元测试的目标是验证单个单元的行为，而不是模拟整个调用链。当一个Mock返回另一个Mock时，它模糊了单元的边界，使得测试更像集成测试。
推荐做法： 如果可能，应尽量避免Mock返回Mock。更好的设计通常意味着：
- 更细粒度的单元：将复杂的逻辑拆分为更小的、职责单一的单元。
- 直接注入所需的Mock：如果SomeClass直接需要A的实例（而不是通过B间接获取），那么应该直接注入A的Mock。
- 使用真实的、轻量级的对象：如果A是一个简单的POJO或值对象，不包含复杂逻辑和外部依赖，那么直接返回一个真实的A实例可能比Mock它更好。
依赖注入：提升可测试性的基石
本教程中采用的Supplier注入模式是依赖注入的一种形式。依赖注入是提升代码可测试性、可维护性和灵活性的关键设计模式。它使得：
- 解耦：模块之间不再紧密耦合，降低了修改一个模块对其他模块的影响。
- 易于测试：在测试环境中，可以轻松替换依赖为Mock或Stub，实现对单个单元的隔离测试。
- 可扩展性：可以更容易地替换或添加新的实现，而无需修改使用它们的客户端代码。
设计可测试的代码
从代码设计初期就考虑如何管理依赖至关重要。避免在类内部直接实例化复杂的、带有外部依赖的对象。相反，应通过以下方式引入依赖：
- 构造函数注入：如本例所示，通过构造函数传递依赖。
- Setter方法注入：通过公共的setter方法设置依赖（适用于可选依赖或循环依赖）。
- 工厂模式：如果对象的创建逻辑复杂，可以使用工厂类来封装创建过程，并注入工厂本身。
总结
当被测试类内部实例化了依赖对象时，传统的Mockito模拟无法直接生效。解决此问题的核心在于通过重构代码，引入依赖注入模式（如Supplier），将被测试类与依赖对象的具体实例化解耦。虽然“Mock返回Mock”的模式可以实现功能，但在实际开发中应谨慎使用，并优先考虑更简洁、更健壮的设计。最终，良好的代码可测试性源于优秀的设计实践，即从一开始就考虑如何管理和注入依赖。
