本文探讨了在使用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，例如：
@MockA a; // 这是一个A的模拟对象@InjectMockSomeClass someClass;@Testvoid 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 bFactory; // 使用Supplier来提供B的实例 // 构造函数，允许外部注入B的创建逻辑 public SomeClass(final Supplier 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(); }}
在这个重构后的版本中：
九歌
九歌–人工智能诗歌写作系统
322 查看详情 SomeClass不再直接使用new B()来创建B的实例，而是通过一个Supplier接口来获取。在生产代码中，可以通过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实践：如何优雅地模拟内部创建对象及其方法返回结果的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1030483.html
微信扫一扫 
支付宝扫一扫 
