本文探讨了在使用mockito进行单元测试时，如何模拟由内部创建对象的方法返回的对象。当被测类与依赖对象紧密耦合时，直接模拟会失败。文章通过重构代码，引入依赖注入或工厂模式，使得内部依赖可被测试框架控制，从而实现对返回对象的有效模拟，并强调了测试中避免过度使用模拟对象的重要性。
1. 理解内部依赖模拟的挑战
在Java中使用Mockito进行单元测试时，一个常见的挑战是模拟那些在被测类内部直接实例化（通过new关键字）的依赖对象，以及这些对象的方法所返回的结果。考虑以下代码结构：
class SomeClass {
public void doSomeThing() {
B b = new B(); // 内部创建B的实例
A a = b.foo(); // 调用B的方法，返回A的实例
a.foo(); // 对返回的A实例进行操作
}
}在上述SomeClass中，B的实例是在doSomeThing方法内部创建的。这意味着SomeClass与B的具体实现紧密耦合。如果我们尝试使用传统的Mockito方式来模拟A，例如：
@Mock
A a; // 这是一个A的模拟对象
@InjectMock
SomeClass someClass;
@Test
void test() {
// 尝试配置a的foo()方法行为
Mockito.when( a.foo() ).thenReturn( something );
assertDoesNotThrow( () -> someClass.doSomeThing() );
}这种测试方法将无法奏效。原因在于，@Mock A a创建的模拟对象与SomeClass内部通过new B().foo()实际获取到的A对象是完全不同的两个实例。SomeClass内部仍然会调用真实的B实例的foo()方法，并获得一个真实的A实例（或者一个未被模拟的A实例），而不是我们期望的模拟A对象。因此，对@Mock A a的配置对SomeClass内部的执行没有任何影响。被测类与依赖的紧密耦合阻止了测试框架介入依赖对象的创建过程。
2. 重构以提升可测试性：引入依赖注入
要解决上述问题，核心在于打破SomeClass与B之间的紧密耦合，使得B的创建过程可以被外部控制，从而在测试时能够注入一个模拟的B实例。一种有效的策略是使用依赖注入（Dependency Injection）模式，或者更具体地，通过提供一个工厂或Supplier来控制依赖的创建。
我们可以将SomeClass重构如下，允许外部注入一个Supplier来提供B的实例：
import java.util.function.Supplier;
class SomeClass {
private final Supplier<? extends B> bFactory; // 使用Supplier来提供B的实例
// 构造函数，允许外部注入B的创建逻辑
public SomeClass(final Supplier<? extends B> bFactory) {
this.bFactory = bFactory;
}
// 无参构造函数，为现有代码提供兼容性，实际应用中建议统一使用带参构造函数
public SomeClass() {
this(B::new); // 默认行为：创建真实的B实例
}
public void doSomeThing() {
B b = this.bFactory.get(); // 从Supplier获取B的实例
A a = b.foo();
a.foo();
}
}在这个重构后的版本中：
- SomeClass不再直接使用new B()来创建B的实例，而是通过一个Supplier接口来获取。
- 在生产代码中，可以通过new SomeClass(B::new)来保持原有的行为。
- 更推荐的做法是，所有依赖SomeClass的地方都通过构造函数注入其所需的Supplier，这进一步提升了模块间的解耦。这种设计遵循了依赖倒置原则，使得SomeClass不再依赖于B的具体实现，而是依赖于一个抽象的Supplier接口。
3. 实施模拟策略
有了重构后的SomeClass，我们现在可以轻松地在测试中注入一个模拟的B实例，进而控制B.foo()的返回值。
import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
// 假设A和B是已定义的类，此处为示例实现
class A {
public void foo() { System.out.println("A's real foo called"); }
}
class B {
public A foo() {
System.out.println("B's real foo called");
return new A();
}
}
class SomeClassTest {
@Test
void testDoSomeThingWithMockedDependencies() {
// 1. 创建A的模拟对象
final A aMock = mock(A.class);
// 配置aMock.foo()的行为（如果aMock.foo()会被调用）。
// 例如，让它什么都不做，或者抛出异常等。
doNothing().when(aMock).foo();
// 2. 创建B的模拟对象
final B bMock = mock(B.class);
// 配置bMock.foo()的行为，使其返回aMock
when(bMock.foo()).thenReturn(aMock);
// 3. 创建SomeClass的实例，并注入一个Supplier，该Supplier返回bMock
// 这样，SomeClass在执行doSomeThing时，会通过bFactory.get()获取到bMock
final SomeClass someClass = new SomeClass(() -> bMock);
// 4. 执行被测方法
assertDoesNotThrow(() -> someClass.doSomeThing());
// 5. 验证交互（可选）：确保方法按预期被调用
verify(bMock).foo(); // 验证bMock的foo方法是否被调用
verify(aMock).foo(); // 验证aMock的foo方法是否被调用
}
}在这个测试中，我们：
- 创建了一个A的模拟对象aMock，并配置了其foo()方法的行为。
- 创建了一个B的模拟对象bMock。
- 配置bMock.foo()方法在被调用时返回aMock。
- 实例化SomeClass时，传入一个Lambda表达式() -> bMock作为Supplier，这样SomeClass内部在需要B实例时，就会得到我们提供的bMock。 通过这种方式，我们成功地控制了SomeClass内部对B和A的依赖，实现了对内部创建对象及其返回结果的模拟。
4. 注意事项与最佳实践
尽管上述方法能够解决内部依赖的模拟问题，但在实际测试中，有几个重要的注意事项和最佳实践需要牢记：
-
避免“模拟返回模拟” (Mocks returning Mocks)： 在上述示例中，我们让bMock返回了aMock。虽然这在某些情况下是必要的，但通常被认为是一种“代码异味”（code smell）。过多的“模拟返回模拟”会使测试变得：
- 脆弱 (Brittle)：测试与实现细节过度耦合。如果B.foo()的返回类型或行为在未来发生变化，即使SomeClass的核心业务逻辑没有改变，测试也可能失败。
- 复杂 (Complex)：增加了测试代码的阅读和维护难度。
- 难以理解 (Hard to understand)：模糊了测试的意图，使得测试不再清晰地表达被测单元的行为。 在设计时，如果发现需要频繁地进行“模拟返回模拟”，这可能暗示着被测单元（如SomeClass）的职责过于庞大，或者其依赖关系过于复杂。此时，应考虑对代码进行进一步的解耦或重构。例如，SomeClass是否真的需要直接操作A的实例？它是否可以将对A的操作委托给另一个服务？
专注于被测单元的行为： 单元测试的目标是验证单个单元（通常是一个类或一个方法）的特定行为，而不是其内部的实现细节。当模拟层级过深时，我们实际上可能在测试多个单元的协作，这更像是集成测试的范畴。尽量使模拟对象只模拟其直接依赖的行为。
重构的价值： 本教程的核心在于通过重构（引入Supplier或依赖注入）来提升代码的可测试性。这种重构不仅有助于单元测试，还能提高代码的模块化程度、可维护性和灵活性。一个设计良好的类应该易于测试，而易于测试的类往往也是设计良好的。
总结
要有效地模拟由内部创建对象的方法返回的对象，关键在于打破被测类与这些内部依赖之间的紧密耦合。通过引入依赖注入或工厂模式（如Supplier），我们可以将依赖的创建控制权转移到外部，从而在单元测试中注入模拟对象。这种方法不仅解决了模拟难题，也促进了更健壮、更灵活的代码设计。虽然这种方法能够解决问题，但务必注意避免过度使用“模拟返回模拟”的模式，并始终将测试的重点放在验证被测单元的外部行为上，而不是其内部实现细节。良好的代码设计是实现高效、可维护单元测试的基础。
