
本文旨在解决Java单元测试中,当目标类内部实例化了BufferedReader等依赖时,Mockito框架无法有效对其进行Mock的问题。核心解决方案是采用依赖注入模式,通过构造函数将Mock对象传入被测试类,从而确保单元测试能够控制外部依赖的行为,避免测试时程序阻塞或行为不可预测,提升测试的隔离性和可靠性。
在进行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实例。
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问题,还带来了诸多额外优势:
注意事项:
在Java单元测试中,正确Mock内部创建的依赖是确保测试有效性的关键。通过采纳依赖注入模式,特别是构造函数注入,我们可以有效地解耦被测试类与其依赖,从而使Mocking成为可能。这种方法不仅解决了测试难题,还提升了代码的整体设计质量,使其更具可测试性、可维护性和扩展性。始终牢记,良好的代码设计是编写高质量单元测试的基础。
以上就是Mockito单元测试:如何正确Mock内部创建的依赖的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号