本文旨在解决Java单元测试中，当目标类内部实例化了BufferedReader等依赖时，Mockito框架无法有效对其进行Mock的问题。核心解决方案是采用依赖注入模式，通过构造函数将Mock对象传入被测试类，从而确保单元测试能够控制外部依赖的行为，避免测试时程序阻塞或行为不可预测，提升测试的隔离性和可靠性。
Java单元测试中Mocking内部实例化依赖的挑战与解决方案
在进行Java单元测试时，我们经常需要模拟（Mock）外部依赖的行为，以确保测试的隔离性和可预测性。然而，当被测试类（System Under Test, SUT）内部直接实例化其依赖对象时，传统的Mockito模拟方法往往会失效，导致测试无法按预期执行，甚至出现程序阻塞等问题。本文将深入探讨这一常见问题，并提供基于依赖注入的有效解决方案。
问题根源：紧耦合与内部实例化
当一个类（例如View类）在其内部方法或构造函数中直接使用new关键字创建其依赖对象（例如BufferedReader）时，就形成了紧耦合。这意味着View类与BufferedReader的具体实现紧密绑定，无法在外部替换。
考虑以下简化示例，其中View类内部实例化了BufferedReader：
import java.io.BufferedReader;import java.io.IOException;import java.io.InputStreamReader;public class View { private final BufferedReader reader; public View() { // 问题所在：BufferedReader在此处被内部实例化 this.reader = new BufferedReader(new InputStreamReader(System.in)); } public void inputCommand() throws IOException { String line; System.out.println("Waiting for command..."); // 添加提示，更清晰 while ((line = reader.readLine()) != null) { System.out.println("Received command: " + line); if ("Q".equals(line.trim())) { // trim() 避免空白字符影响判断 System.out.println("Exiting command input."); break; } // 可以在此处添加处理命令的逻辑 } }}
在上述View类的构造函数中，BufferedReader被直接实例化。当我们在测试中尝试像这样模拟BufferedReader时：
import org.junit.jupiter.api.Test;import java.io.BufferedReader;import java.io.IOException;import static org.mockito.Mockito.*;public class ViewTestFails { @Test void whenCommandIsR_CallBuildRectangle_Fails() throws IOException { BufferedReader bufferedReader = mock(BufferedReader.class); // 尝试为mock对象设置行为 when(bufferedReader.readLine()).thenReturn("C 10 10").thenReturn("Q"); // 此时View内部创建了它自己的BufferedReader实例，而非我们mock的实例 View view = new View(); view.inputCommand(); // 这里的verify将失败，因为View使用的是内部实例，而非我们mock的实例 // 并且测试会阻塞，等待System.in的真实输入 verify(bufferedReader, times(2)).readLine(); }}
测试中创建的mock(BufferedReader.class)实例与View类内部使用的BufferedReader实例是完全不同的对象。因此，对Mock对象设置的when().thenReturn()规则不会影响到View类实际调用的reader.readLine()方法，View类仍会尝试从System.in读取真实输入，导致测试阻塞或行为异常。
解决方案：依赖注入（构造函数注入）
解决内部实例化依赖问题的核心在于解耦，即让被测试类不再负责创建其依赖，而是从外部接收这些依赖。依赖注入（Dependency Injection, DI）是一种实现这一目标的强大模式。其中，构造函数注入是最常用且推荐的方式之一。
通过构造函数注入，我们将BufferedReader对象作为View类构造函数的参数传入。这样，在生产代码中可以传入真实的BufferedReader实例，而在单元测试中则可以传入我们精心准备的Mock实例。
Remove.bg
AI在线抠图软件，图片去除背景
174 查看详情 
1. 修改被测试类（View）以支持构造函数注入：
import java.io.BufferedReader;import java.io.IOException;import java.io.InputStreamReader;public class View { private final BufferedReader reader; // 修改为构造函数注入：View类不再创建BufferedReader，而是接收它 public View(BufferedReader reader) { this.reader = reader; } // 可选：提供一个无参构造函数，用于生产环境，以保持与旧代码的兼容性 // 或者当View总是需要从System.in读取时 public View() { this(new BufferedReader(new InputStreamReader(System.in))); } public void inputCommand() throws IOException { String line; System.out.println("Waiting for command..."); while ((line = reader.readLine()) != null) { System.out.println("Received command: " + line); if ("Q".equals(line.trim())) { System.out.println("Exiting command input."); break; } // 实际应用中，这里会包含处理用户输入的业务逻辑 } }}
2. 修正单元测试：
现在，我们可以在测试中创建BufferedReader的Mock实例，并通过View类的构造函数将其注入。
import org.junit.jupiter.api.Test;import java.io.BufferedReader;import java.io.IOException;import static org.mockito.Mockito.*;import static org.junit.jupiter.api.Assertions.*; // 引入断言，用于更全面的测试public class ViewTest { @Test void whenCommandIsC_ThenProcessCommandAndExit() throws IOException { // 1. 创建Mock对象 BufferedReader mockBufferedReader = mock(BufferedReader.class); // 2. 定义Mock对象的行为 // 第一次调用readLine()返回"C 10 10"，第二次返回"Q" when(mockBufferedReader.readLine()) .thenReturn("C 10 10") .thenReturn("Q"); // 模拟用户输入"Q"退出 // 3. 将Mock对象注入到被测试类中 View view = new View(mockBufferedReader); // 4. 执行被测试方法 view.inputCommand(); // 5. 验证Mock对象的行为 // 验证readLine()方法被调用了两次 verify(mockBufferedReader, times(2)).readLine(); // 可以在此处添加更多断言，例如验证View类内部的业务逻辑是否正确执行 // 假设View有一个方法可以获取处理过的命令列表，可以这样验证： // assertEquals(Arrays.asList("C 10 10"), view.getProcessedCommands()); } @Test void whenCommandIsQImmediately_ThenExit() throws IOException { BufferedReader mockBufferedReader = mock(BufferedReader.class); // 模拟用户直接输入"Q" when(mockBufferedReader.readLine()).thenReturn("Q"); View view = new View(mockBufferedReader); view.inputCommand(); // 验证readLine()方法只被调用了一次 verify(mockBufferedReader, times(1)).readLine(); }}
通过上述修改，单元测试现在能够完全控制View类所依赖的BufferedReader的行为，从而实现真正的隔离测试。测试将不再阻塞，并且能够按照预设的Mock行为快速执行。
依赖注入的优势与最佳实践
采用依赖注入模式不仅解决了Mocking问题，还带来了诸多额外优势：
提高可测试性：这是最直接的好处。依赖可以轻松替换为Mock、Stub或Fake对象，使得单元测试变得简单高效，确保测试的隔离性和可重复性。降低耦合度：类不再硬编码其依赖的创建过程，而是通过接口或抽象类与依赖交互，增强了模块间的独立性。提高可维护性与可扩展性：当依赖发生变化时，只需修改注入点，而无需修改所有使用该依赖的类。引入新的依赖或切换实现也变得更加容易。促进单一职责原则（SRP）：一个类专注于其核心业务逻辑，而不必关心依赖的实例化细节。
注意事项：
选择合适的注入方式：除了构造函数注入，还有Setter注入和接口注入。构造函数注入通常是首选，因为它确保了对象在创建时就拥有所有必要的依赖，且这些依赖是不可变的，有助于创建更健壮的对象。避免过度注入：如果一个类的构造函数需要过多的参数（通常超过3-5个），这可能是一个信号，表明该类承担了过多的职责，需要考虑重构以遵循单一职责原则。结合依赖注入框架：对于大型项目，手动管理依赖注入会变得复杂。Spring、Guice等DI框架能够自动化依赖的创建和注入过程，进一步简化开发和配置。
总结
在Java单元测试中，正确Mock内部创建的依赖是确保测试有效性的关键。通过采纳依赖注入模式，特别是构造函数注入，我们可以有效地解耦被测试类与其依赖，从而使Mocking成为可能。这种方法不仅解决了测试难题，还提升了代码的整体设计质量，使其更具可测试性、可维护性和扩展性。始终牢记，良好的代码设计是编写高质量单元测试的基础。
以上就是Mockito单元测试：如何正确Mock内部创建的依赖的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/968075.html
微信扫一扫 
支付宝扫一扫 
