首页 > Java > java教程 > 正文

Mockito实践:如何模拟方法返回的对象并重构提升可测试性

心靈之曲
发布: 2025-11-13 14:16:30
原创
121人浏览过

Mockito实践:如何模拟方法返回的对象并重构提升可测试性

本文探讨了在java和mockito中,当被测试类内部实例化了依赖对象时,如何模拟该依赖对象方法返回值的挑战。我们将解释直接模拟的局限性,并提供一种通过引入依赖注入(如`supplier`)来重构代码以提升可测试性的解决方案。教程还将涵盖测试中模拟对象的最佳实践和注意事项。

理解问题:为何直接模拟失效?

在单元测试中,我们经常需要模拟(mock)依赖对象的行为,以隔离被测试单元。然而,当依赖对象在被测试类内部被实例化时,传统的Mockito模拟方法会失效。考虑以下示例代码:

class A {
    public String foo() {
        return "Real A's foo";
    }
}

class B {
    public A foo() {
        return new A(); // B的foo方法内部创建并返回A的实例
    }
}

class SomeClass {
    public void doSomeThing() {
        B b = new B(); // SomeClass内部创建B的实例
        A a = b.foo();
        System.out.println(a.foo());
    }
}
登录后复制

在这种结构中,SomeClass直接在doSomeThing方法内部创建了B的实例,而B的foo方法又内部创建了A的实例。当尝试对SomeClass进行测试时,我们可能会尝试以下方式来模拟A的行为:

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

class SomeClassTest {

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

    @InjectMocks
    SomeClass someClass;

    @Test
    void testDoSomeThing() {
        // 期望aMock的foo方法返回特定值,但这种模拟不会生效
        Mockito.when(aMock.foo()).thenReturn("Mocked A's foo");

        // 执行doSomeThing方法
        assertDoesNotThrow(() -> someClass.doSomeThing());
        // 实际上,doSomeThing内部创建的是真实的A和B,aMock并未被使用
    }
}
登录后复制

上述测试尝试通过@Mock A aMock来模拟A,但这种方式是无效的。原因在于,SomeClass内部通过new B()创建了一个真实的B对象,进而B的foo()方法也返回了一个真实的A对象。Mockito无法拦截或替换这些在被测试类内部通过new关键字创建的实例。SomeClass与B之间,以及B与A之间,存在紧密的耦合,它们依赖于具体的实现而非抽象。

解决方案:重构代码以提升可测试性

要解决这个问题,核心思想是解耦:将被测试类内部创建依赖对象的职责转移出去,使其能够通过外部注入的方式获得依赖。这通常通过依赖注入(Dependency Injection, DI)模式实现。

我们可以通过引入一个工厂或Supplier接口来提供B的实例,而不是在SomeClass内部直接创建它。这样,在测试时,我们就可以注入一个提供模拟B对象的Supplier。

重构后的SomeClass

import java.util.function.Supplier;

class SomeClass {
  // 使用Supplier来延迟和抽象B的创建
  private final Supplier<? extends B> bFactory;

  // 推荐的构造函数:通过Supplier注入B的创建逻辑
  public SomeClass(final Supplier<? extends B> bFactory) {
    this.bFactory = bFactory;
  }

  // 可选的无参构造函数,用于兼容旧代码或简化生产环境的实例化
  // 在实际项目中,也应尽量通过DI框架管理依赖,避免手动new SomeClass()
  public SomeClass() {
    this(B::new); // 默认使用B的真实构造函数
  }

  public void doSomeThing() {
    B b = this.bFactory.get(); // 从工厂获取B的实例
    A a = b.foo();
    System.out.println(a.foo());
  }
}
登录后复制

在这个重构后的SomeClass中:

  • 我们引入了一个Supplier<? extends B> bFactory字段。Supplier是一个函数式接口,其get()方法不接受参数并返回一个结果。
  • SomeClass的构造函数现在接受一个Supplier,允许外部控制B的实例化方式。
  • doSomeThing方法通过this.bFactory.get()来获取B的实例,而不是直接new B()。
  • 提供一个无参构造函数是为了方便迁移或在非测试环境下使用,它默认使用B::new(一个方法引用,等同于() -> new B())作为Supplier。

编写可测试的代码:Mocking实践

现在,有了重构后的SomeClass,我们就可以在测试中轻松地注入模拟的B实例,进而控制A的返回行为。

标书对比王
标书对比王

标书对比王是一款标书查重工具,支持多份投标文件两两相互比对,重复内容高亮标记,可快速定位重复内容原文所在位置,并可导出比对报告。

标书对比王 58
查看详情 标书对比王
import org.junit.jupiter.api.Test;
import org.mockito.Mockito;
import static org.junit.jupiter.api.Assertions.assertDoesNotThrow;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

class SomeClassTest {

    @Test
    void testDoSomeThingWithMocks() {
        // 1. 模拟A对象
        final A aMock = mock(A.class);
        // 配置aMock的行为,例如当调用aMock.foo()时返回特定值
        when(aMock.foo()).thenReturn("Mocked A's foo from test");

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

        // 3. 创建一个Supplier,使其在调用get()时返回bMock
        // 这样,当SomeClass请求B的实例时,会得到我们的bMock
        final SomeClass someClass = new SomeClass(() -> bMock);

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

        // 验证bMock的foo方法是否被调用
        Mockito.verify(bMock).foo();
        // 验证aMock的foo方法是否被调用
        Mockito.verify(aMock).foo();
    }
}
登录后复制

通过这种方式,我们成功地控制了SomeClass内部对B和A的依赖,使得测试可以完全隔离并验证SomeClass自身的逻辑。

注意事项与最佳实践

警惕“Mock返回Mock”的模式

尽管上述解决方案能够实现对内部实例化对象的模拟,但测试中出现“Mock返回Mock”(即when(bMock.foo()).thenReturn(aMock))的模式通常被认为是不良实践

  • 测试脆弱性:这种测试过度耦合到被测试单元的实现细节。如果B.foo()返回的对象类型或其行为在未来发生变化,即使SomeClass的逻辑没有改变,测试也可能失败。
  • 复杂性增加:测试代码变得更复杂,难以理解和维护。
  • 违反单元测试原则:单元测试的目标是验证单个单元的行为,而不是模拟整个调用链。当一个Mock返回另一个Mock时,它模糊了单元的边界,使得测试更像集成测试。

推荐做法: 如果可能,应尽量避免Mock返回Mock。更好的设计通常意味着:

  1. 更细粒度的单元:将复杂的逻辑拆分为更小的、职责单一的单元。
  2. 直接注入所需的Mock:如果SomeClass直接需要A的实例(而不是通过B间接获取),那么应该直接注入A的Mock。
  3. 使用真实的、轻量级的对象:如果A是一个简单的POJO或值对象,不包含复杂逻辑和外部依赖,那么直接返回一个真实的A实例可能比Mock它更好。

依赖注入:提升可测试性的基石

本教程中采用的Supplier注入模式是依赖注入的一种形式。依赖注入是提升代码可测试性、可维护性和灵活性的关键设计模式。它使得:

  • 解耦:模块之间不再紧密耦合,降低了修改一个模块对其他模块的影响。
  • 易于测试:在测试环境中,可以轻松替换依赖为Mock或Stub,实现对单个单元的隔离测试。
  • 可扩展性:可以更容易地替换或添加新的实现,而无需修改使用它们的客户端代码。

设计可测试的代码

从代码设计初期就考虑如何管理依赖至关重要。避免在类内部直接实例化复杂的、带有外部依赖的对象。相反,应通过以下方式引入依赖:

  • 构造函数注入:如本例所示,通过构造函数传递依赖。
  • Setter方法注入:通过公共的setter方法设置依赖(适用于可选依赖或循环依赖)。
  • 工厂模式:如果对象的创建逻辑复杂,可以使用工厂类来封装创建过程,并注入工厂本身。

总结

当被测试类内部实例化了依赖对象时,传统的Mockito模拟无法直接生效。解决此问题的核心在于通过重构代码,引入依赖注入模式(如Supplier),将被测试类与依赖对象的具体实例化解耦。虽然“Mock返回Mock”的模式可以实现功能,但在实际开发中应谨慎使用,并优先考虑更简洁、更健壮的设计。最终,良好的代码可测试性源于优秀的设计实践,即从一开始就考虑如何管理和注入依赖。

以上就是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号