本文旨在解决在单元测试中，当被测试类内部创建了依赖对象，且需要模拟该依赖对象方法返回的另一个对象时遇到的挑战。通过深入探讨紧耦合问题，并提出使用依赖注入（通过`supplier`接口）重构代码的策略，文章详细演示了如何有效地模拟内部创建对象的行为，从而实现更彻底和可维护的单元测试。
在进行单元测试时，我们经常需要模拟外部依赖的行为，以确保只测试当前类的逻辑。然而，当被测试类（System Under Test, SUT）内部直接实例化其依赖对象时，传统的模拟方法往往会失效。本文将以一个具体的Java示例，深入探讨这一问题，并提供基于重构和依赖注入的解决方案。
1. 问题场景：内部创建依赖导致测试困难
考虑以下Java类结构： SomeClass在其doSomeThing方法中创建了B的实例，然后调用b.foo()，该方法返回一个A的实例，最后又调用了a.foo()。
class SomeClass {
public void doSomeThing() {
B b = new B(); // B的实例在内部创建
A a = b.foo();
a.foo();
}
}
// 假设 A 和 B 是其他类
class A {
public void foo() { /* 实际逻辑 */ }
}
class B {
public A foo() { return new A(); /* 实际逻辑 */ }
}我们的目标是测试SomeClass.doSomeThing()方法，并希望模拟b.foo()返回的A对象，甚至模拟A对象上的foo()方法。
初学者可能会尝试以下测试方法：
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
class SomeClassTest {
@Mock
A aMock; // 尝试模拟 A
@InjectMocks
SomeClass someClass;
@Test
void testInitialAttempt() {
// 尝试模拟 aMock 的行为
Mockito.when(aMock.foo()).thenReturn( /* some value or do nothing */ );
// 执行被测方法
assertDoesNotThrow(() -> someClass.doSomeThing());
}
}然而，上述测试将无法达到预期效果。原因在于SomeClass内部通过new B()直接创建了B的实例。这意味着，在someClass.doSomeThing()执行时，它调用的是B的真实实现，而不是一个Mockito模拟对象。因此，b.foo()将返回一个真实的A对象，而不是我们通过@Mock A aMock创建的模拟对象，对aMock的配置也就毫无作用。
2. 核心问题：紧耦合与不可测试性
问题的根源在于SomeClass与B的紧密耦合。SomeClass直接依赖于B的具体实现，并且控制了B实例的生命周期（通过new B()）。这种设计模式使得我们无法在不修改SomeClass代码的情况下，替换掉B的真实行为，从而无法有效地进行单元测试。为了实现可测试性，我们需要解耦SomeClass和B的创建过程。
3. 解决方案：重构为可测试设计（依赖注入）
要解决这一问题，我们需要对SomeClass进行重构，使其能够“注入”B的创建方式，而不是在内部硬编码。一种常见的做法是使用依赖注入，特别是对于对象创建的场景，可以注入一个工厂或Supplier。
我们将SomeClass重构如下，引入一个Supplier<B>来提供B的实例：
import java.util.function.Supplier;
class SomeClass {
private final Supplier<? extends B> bFactory;
// 构造函数，允许外部注入 B 的创建方式
public SomeClass(final Supplier<? extends B> bFactory) {
this.bFactory = bFactory;
}
// 为了向后兼容或简化迁移，可以提供一个无参构造函数，
// 它使用默认的 B 实例创建方式。在生产代码中，
// 推荐始终使用带参数的构造函数。
public SomeClass() {
this(B::new);
}
public void doSomeThing() {
B b = this.bFactory.get(); // 从 Supplier 获取 B 实例
A a = b.foo();
a.foo();
}
}通过这种方式，SomeClass不再直接创建B的实例，而是通过bFactory.get()方法获取。在生产环境中，这个Supplier可以提供真实的B实例；而在测试环境中，我们可以提供一个返回模拟B实例的Supplier。
4. 编写有效的单元测试
有了重构后的SomeClass，我们现在可以编写一个有效的单元测试来模拟b.foo()返回的A对象。
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import java.util.function.Supplier;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
class SomeClassRefactoredTest {
@Test
void testWithRefactoredClass() {
// 1. 模拟 A 对象
final A aMock = mock(A.class);
// 配置 aMock 的行为，例如当 aMock.foo() 被调用时
// 这里只是示例，实际可能需要thenReturn()一个值或doNothing()
when(aMock.foo()).thenAnswer(invocation -> {
System.out.println("aMock.foo() was called!");
return null; // 或者返回一个具体值
});
// 2. 模拟 B 对象
final B bMock = mock(B.class);
// 配置 bMock 的行为：当 bMock.foo() 被调用时，返回 aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建一个 Supplier，使其在被调用时返回 bMock
final Supplier<B> bSupplierMock = () -> bMock;
// 4. 使用这个 Supplier 实例化 SomeClass
final SomeClass someClass = new SomeClass(bSupplierMock);
// 5. 执行被测方法并验证
assertDoesNotThrow(() -> someClass.doSomeThing());
// 可选：验证 mock 对象的交互
Mockito.verify(bMock).foo(); // 验证 bMock 的 foo() 方法被调用
Mockito.verify(aMock).foo(); // 验证 aMock 的 foo() 方法被调用
}
}在这个测试中：
- 我们首先创建了A和B的模拟对象 (aMock和bMock)。
- 我们配置bMock，使其在调用foo()方法时返回aMock。
- 我们创建了一个Supplier<B>的Lambda表达式，它在调用get()时会返回bMock。
- 最后，我们使用这个Supplier来实例化SomeClass。这样，当someClass.doSomeThing()执行时，它会通过bFactory.get()获取到我们提供的bMock，从而使得后续的bMock.foo()调用能够返回aMock，进而我们能控制aMock.foo()的行为。
5. 注意事项与最佳实践
尽管上述方法能够有效解决问题，但需要注意以下几点：
- “模拟返回模拟”的权衡： 在测试中让一个模拟对象返回另一个模拟对象（如bMock.foo()返回aMock）通常被认为是不好的实践。这种设置会使测试变得脆弱、不必要地复杂，并且与实现细节紧密耦合。如果B.foo()的实际实现逻辑改变，即使SomeClass的逻辑不变，测试也可能失败。
- 测试的粒度： 理想的单元测试应该只关注被测试类的行为，并尽可能少地依赖于其依赖项的内部实现细节。如果B.foo()返回A的逻辑是B的核心职责，那么应该在B的单元测试中验证它。在SomeClass的测试中，我们可能只需要关心SomeClass是否正确地使用了B返回的A。
- 设计模式的思考： 这种通过Supplier注入依赖的方式，实际上是一种轻量级的工厂模式。在更复杂的场景中，可以考虑使用更正式的工厂模式或抽象工厂模式来管理对象的创建。
- 重构的价值： 本文的重点在于通过重构提高代码的可测试性。一个设计良好的类，其依赖关系应该清晰且易于替换，这不仅有助于测试，也有利于代码的维护和扩展。
总结
当被测试类内部创建了其依赖对象，并且需要模拟该依赖对象方法返回的另一个对象时，直接的Mockito模拟会失效。核心解决方案在于重构被测试类，引入依赖注入机制（如通过Supplier接口），将依赖对象的创建过程外部化。这使得测试能够提供模拟的依赖对象，从而实现对被测试类行为的有效隔离和验证。虽然“模拟返回模拟”在某些情况下是必要的，但应谨慎使用，并优先考虑更简洁、更少耦合的测试策略。一个可测试的设计是高质量软件的重要标志。
