Java单元测试：解耦内部依赖以模拟方法返回对象

日期：2025-11-13 00:00 / 作者：花韻仙語

本文探讨了在java单元测试中，当被测类内部创建依赖对象时，如何有效模拟该对象方法返回值的挑战。通过引入依赖注入和`supplier`模式进行代码重构，文章展示了如何解耦紧密耦合的组件，从而实现对内部创建对象行为的精确模拟。同时，文章强调了在测试中避免“模拟返回模拟”的实践建议，以确保测试的健壮性和可维护性。

理解问题：内部依赖的测试困境

在编写单元测试时，一个常见且棘手的场景是，当被测试的类（例如SomeClass）在其方法内部直接创建并使用其他类的实例（例如B），并且我们希望模拟该内部创建对象（B）所返回的另一个对象（A）的行为时。这种模式导致了被测类与它所依赖的具体实现之间的高度耦合，从而严重阻碍了单元测试的进行。

考虑以下代码结构：

class SomeClass {
    public void doSomeThing() {
        B b = new B(); // B的实例在内部创建
        A a = b.foo(); // 我们希望模拟a的行为
        a.foo();
    }
}

class B {
    public A foo() {
        // 实际的业务逻辑，返回一个A的实例
        return new A(); 
    }
}

class A {
    public void foo() {
        // A的业务逻辑
    }
}

在这种情况下，如果尝试使用Mockito等模拟框架直接模拟A，例如通过@Mock注解，并期望它在SomeClass中被使用：

import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;

class SomeClassTest {

    @Mock
    A aMock; // 尝试模拟A

    @InjectMocks
    SomeClass someClass; // 注入SomeClass实例

    @Test
    void test() {
        // 配置aMock的foo()方法行为
        // Mockito.when(aMock.foo()).thenReturn(something); // 如果A.foo()有返回值

        // 执行被测试的方法
        assertDoesNotThrow(() -> someClass.doSomeThing());
    }
}

这样的测试是无法成功的。核心原因在于，SomeClass内部通过new B()创建了一个B的实际实例，而不是一个模拟实例。因此，当b.foo()被调用时，它将执行真实B对象的方法，返回一个真实的A对象（或者抛出空指针异常，如果B.foo()返回null），而不是我们通过@Mock注解创建并配置的aMock。这明确指出SomeClass与B之间存在紧密的耦合，使得SomeClass对B的具体实现产生了依赖，从而降低了代码的可测试性。

解决方案：重构以实现依赖注入

要解决这种紧密耦合带来的测试难题，核心思想是重构代码，使SomeClass不再直接负责B实例的创建，而是通过依赖注入的方式获取B的实例或其创建方式。这样，在测试时，我们就可以注入一个模拟的B实例或一个能提供模拟B实例的工厂。

一种有效的重构方式是引入Java 8的Supplier接口。Supplier是一个函数式接口，它不接受任何参数，但会返回一个结果。通过将Supplier注入到SomeClass中，我们允许外部提供B实例的创建逻辑。

import java.util.function.Supplier;

class SomeClass {
  private final Supplier bFactory; // 注入B的工厂

  /**
   * 构造函数：接受一个Supplier来提供B实例的创建逻辑。
   * 这是实现依赖注入的关键。
   * @param bFactory 提供B实例的Supplier
   */
  public SomeClass(final Supplier bFactory) {
    this.bFactory = bFactory;
  }

  /**
   * 无参构造函数：提供默认行为，便于现有代码迁移或生产环境使用。
   * 默认使用B的无参构造函数创建B实例。
   */
  public SomeClass() {
    this(B::new); 
  }

  public void doSomeThing() {
    B b = this.bFactory.get(); // 通过Supplier获取B实例
    A a = b.foo();
    a.foo();
  }
}

在这个重构后的版本中：

SomeClass不再直接调用new B()，而是持有一个Supplier实例。
bFactory.get()方法负责在运行时提供B的实例。
我们提供了一个带Supplier参数的构造函数，允许在测试时注入自定义的B创建逻辑（例如，一个返回模拟B对象的Supplier）。
为了不影响现有生产代码或简化迁移，我们还提供了一个无参构造函数，它默认使用B::new（即B类的默认构造函数）作为Supplier。

测试实践：模拟与验证

通过上述重构，我们现在可以轻松地在单元测试中模拟B和A的行为。

import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;

class SomeClassTest {

    @Test
    void testDoSomeThingWithMocks() {
        // 1. 模拟A对象
        final A aMock = mock(A.class);
        // 如果A.foo()有返回值，可以在这里配置aMock的行为
        // when(aMock.foo()).thenReturn(someValue); 

        // 2. 模拟B对象
        final B bMock = mock(B.class);
        // 关键一步：配置bMock的foo()方法，使其返回我们模拟的aMock
        when(bMock.foo()).thenReturn(aMock);

        // 3. 创建SomeClass实例，注入一个Supplier，使其提供bMock
        // 当SomeClass调用bFactory.get()时，会得到bMock
        final SomeClass someClass = new SomeClass(() -> bMock);

        // 4. 执行被测试的方法
        assertDoesNotThrow(() -> someClass.doSomeThing());

        // 5. 验证模拟对象的交互（可选但推荐）
        // 验证bMock的foo()方法是否被调用
        verify(bMock).foo(); 
        // 验证aMock的foo()方法是否被调用
        verify(aMock).foo(); 
    }
}

在这个测试案例中：

我们首先使用mock()方法创建了A和B的模拟对象 (aMock 和 bMock)。
关键一步是配置bMock.foo()方法，使其返回aMock。这样，当SomeClass通过bFactory.get().foo()获取A时，它实际上会得到我们模拟的aMock。
然后，我们通过带Supplier参数的构造函数创建SomeClass实例，传入一个Lambda表达式 () -> bMock。这个Supplier在被SomeClass调用get()方法时，会返回我们预设的bMock。
最后，执行someClass.doSomeThing()并验证其行为。assertDoesNotThrow用于确认方法执行过程中没有抛出预期之外的异常。
通过verify()方法，我们可以进一步验证模拟对象的方法是否按照预期被调用，增强测试的严谨性。

最佳实践与注意事项

尽管上述方法能够有效解决内部依赖的模拟问题，但仍需注意以下几点，以确保测试的健壮性和代码的可维护性：

避免“模拟返回模拟” (Mocks Returning Mocks)：在上述示例中，我们让bMock返回了aMock。这种“模拟返回模拟”的模式虽然在某些特定场景下可行，但通常被认为是代码异味的信号。它可能导致测试变得脆弱、复杂，并且与实现细节过度耦合。理想情况下，模拟对象应该返回简单的数据或行为，而不是另一个模拟对象。如果经常需要这样做，可能意味着被测试类的职责过于复杂，或者设计上存在改进空间。
设计可测试性：从一开始就将可测试性纳入设计考量，可以避免后续的重构工作。例如，使用工厂模式、抽象工厂模式或依赖注入框架（如Spring、Guice）来管理依赖的创建和生命周期，可以使代码更易于测试和维护。
接口优先原则：尽可能地针对接口而不是具体实现进行编程和模拟。如果B和A是接口，那么模拟它们的行为会更加灵活，且能更好地体现面向接口编程的优势。
测试粒度：单元测试应关注单个单元（通常是一个类或方法）的行为。如果一个测试需要模拟多个层次的依赖，可能意味着测试的粒度过大，或者被测试的单元职责过多，需要进一步拆分。

总结

当被测类内部直接创建依赖对象时，传统的模拟方法往往无法奏效。通过对代码进行重构，引入Supplier等依赖注入机制，我们可以有效地解耦组件，从而在单元测试中精确控制并模拟内部创建对象的行为。这不仅提高了代码的可测试性，也促使我们编写出更灵活、更易于维护的模块化代码。然而，在实践中，我们应当时刻警惕“模拟返回模拟”等可能导致测试脆弱的反模式，并始终坚持“为可测试性而设计”的原则，以构建健壮、可维护的软件系统。