本文探讨了在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 bFactory; // 推荐的构造函数：通过Supplier注入B的创建逻辑 public SomeClass(final Supplier 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 bFactory字段。Supplier是一个函数式接口，其get()方法不接受参数并返回一个结果。SomeClass的构造函数现在接受一个Supplier，允许外部控制B的实例化方式。doSomeThing方法通过this.bFactory.get()来获取B的实例，而不是直接new B()。提供一个无参构造函数是为了方便迁移或在非测试环境下使用，它默认使用B::new（一个方法引用，等同于() -> new B()）作为Supplier。
编写可测试的代码：Mocking实践
现在，有了重构后的SomeClass，我们就可以在测试中轻松地注入模拟的B实例，进而控制A的返回行为。
九歌
九歌–人工智能诗歌写作系统
322 查看详情
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。更好的设计通常意味着：
更细粒度的单元：将复杂的逻辑拆分为更小的、职责单一的单元。直接注入所需的Mock：如果SomeClass直接需要A的实例（而不是通过B间接获取），那么应该直接注入A的Mock。使用真实的、轻量级的对象：如果A是一个简单的POJO或值对象，不包含复杂逻辑和外部依赖，那么直接返回一个真实的A实例可能比Mock它更好。
依赖注入：提升可测试性的基石
本教程中采用的Supplier注入模式是依赖注入的一种形式。依赖注入是提升代码可测试性、可维护性和灵活性的关键设计模式。它使得：
解耦：模块之间不再紧密耦合，降低了修改一个模块对其他模块的影响。易于测试：在测试环境中，可以轻松替换依赖为Mock或Stub，实现对单个单元的隔离测试。可扩展性：可以更容易地替换或添加新的实现，而无需修改使用它们的客户端代码。
设计可测试的代码
从代码设计初期就考虑如何管理依赖至关重要。避免在类内部直接实例化复杂的、带有外部依赖的对象。相反，应通过以下方式引入依赖：
构造函数注入：如本例所示，通过构造函数传递依赖。Setter方法注入：通过公共的setter方法设置依赖（适用于可选依赖或循环依赖）。工厂模式：如果对象的创建逻辑复杂，可以使用工厂类来封装创建过程，并注入工厂本身。
总结
当被测试类内部实例化了依赖对象时，传统的Mockito模拟无法直接生效。解决此问题的核心在于通过重构代码，引入依赖注入模式（如Supplier），将被测试类与依赖对象的具体实例化解耦。虽然“Mock返回Mock”的模式可以实现功能，但在实际开发中应谨慎使用，并优先考虑更简洁、更健壮的设计。最终，良好的代码可测试性源于优秀的设计实践，即从一开始就考虑如何管理和注入依赖。
以上就是Mockito实践：如何模拟方法返回的对象并重构提升可测试性的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1090555.html
微信扫一扫 
支付宝扫一扫 
