本文旨在解决在单元测试中，当被测试类内部创建了依赖对象，且需要模拟该依赖对象方法返回的另一个对象时遇到的挑战。通过深入探讨紧耦合问题，并提出使用依赖注入（通过`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的实例：
TextCortex
AI写作能手，在几秒钟内创建内容。
62 查看详情
import java.util.function.Supplier;class SomeClass { private final Supplier bFactory; // 构造函数，允许外部注入 B 的创建方式 public SomeClass(final Supplier 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 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() 方法被调用 }}
在这个测试中：
我们首先创建了A和B的模拟对象 (aMock和bMock)。我们配置bMock，使其在调用foo()方法时返回aMock。我们创建了一个Supplier的Lambda表达式，它在调用get()时会返回bMock。最后，我们使用这个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中模拟方法返回的对象：重构与依赖注入实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1030532.html
微信扫一扫 
支付宝扫一扫 
