如何在Mockito中模拟方法返回的对象：重构与依赖注入实践

本文旨在解决在单元测试中，当被测试类内部创建了依赖对象，且需要模拟该依赖对象方法返回的另一个对象时遇到的挑战。通过深入探讨紧耦合问题，并提出使用依赖注入（通过`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的实例：

Type Studio

一个视频编辑器，提供自动转录、自动生成字幕、视频翻译等功能

下载

import java.util.function.Supplier;

class SomeClass {
  private final Supplier bFactory;

  // 构造函数，允许外部注入 B 的创建方式
  public SomeClass(final Supplier 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 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() 方法被调用
    }
}

在这个测试中：