Mockito实践：如何优雅地模拟内部创建对象及其方法返回结果-java教程-PHP中文网

Mockito实践：如何优雅地模拟内部创建对象及其方法返回结果

花韻仙語

发布： 2025-11-13 22:05:15

原创

147人浏览过

Mockito实践：如何优雅地模拟内部创建对象及其方法返回结果

本文探讨了在使用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();
  }
}

登录后复制

在这个重构后的版本中：

YOYA优雅

多模态AI内容创作平台

106

查看详情

SomeClass不再直接使用new B()来创建B的实例，而是通过一个Supplier<B>接口来获取。
在生产代码中，可以通过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），我们可以将依赖的创建控制权转移到外部，从而在单元测试中注入模拟对象。这种方法不仅解决了模拟难题，也促进了更健壮、更灵活的代码设计。虽然这种方法能够解决问题，但务必注意避免过度使用“模拟返回模拟”的模式，并始终将测试的重点放在验证被测单元的外部行为上，而不是其内部实现细节。良好的代码设计是实现高效、可维护单元测试的基础。

以上就是Mockito实践：如何优雅地模拟内部创建对象及其方法返回结果的详细内容，更多请关注php中文网其它相关文章！