首页 > Java > java教程 > 正文

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

花韻仙語
发布: 2025-11-13 21:39:01
原创
891人浏览过

如何在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>来提供B的实例:

即构数智人
即构数智人

即构数智人是由即构科技推出的AI虚拟数字人视频创作平台,支持数字人形象定制、短视频创作、数字人直播等。

即构数智人 36
查看详情 即构数智人
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() 方法被调用
    }
}
登录后复制

在这个测试中:

  1. 我们首先创建了A和B的模拟对象 (aMock和bMock)。
  2. 我们配置bMock,使其在调用foo()方法时返回aMock。
  3. 我们创建了一个Supplier<B>的Lambda表达式,它在调用get()时会返回bMock。
  4. 最后,我们使用这个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接口),将依赖对象的创建过程外部化。这使得测试能够提供模拟的依赖对象,从而实现对被测试类行为的有效隔离和验证。虽然“模拟返回模拟”在某些情况下是必要的,但应谨慎使用,并优先考虑更简洁、更少耦合的测试策略。一个可测试的设计是高质量软件的重要标志。

以上就是如何在Mockito中模拟方法返回的对象:重构与依赖注入实践的详细内容,更多请关注php中文网其它相关文章!

最佳 Windows 性能的顶级免费优化软件
最佳 Windows 性能的顶级免费优化软件

每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。

下载
来源:php中文网
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
最新问题
热门推荐
开源免费商场系统广告
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 举报中心 意见反馈 讲师合作 广告合作 最新更新 English
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习

Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号