本文旨在解决在使用Mockito进行单元测试时，服务层方法中对Optional类型返回值（如userRepository.findById()）进行isEmpty()检查时，因未正确stubbing导致默认返回空Optional，进而抛出NotFoundException的问题。我们将详细分析Mockito的默认行为，并提供正确的stubbing策略，确保测试流程按预期执行。
在开发基于Spring Boot等框架的应用时，服务层通常会与数据访问层（Repository）交互。当服务层方法需要根据ID查询实体时，常见的模式是使用Optional来处理查找结果，并根据Optional是否为空来决定后续操作，例如抛出“未找到”异常。然而，在编写单元测试时，如果对Repository的findById等方法没有进行适当的stubbing（模拟），Mockito的默认行为可能会导致测试失败。
问题分析：服务层与Repository交互
考虑以下服务层中的updateUser方法：
@Overridepublic UserDTO updateUser(String id, UserDTO updatedUser) { // 根据updatedUser的userName字段查找用户 Optional databaseUser = userRepository.findById(Integer.valueOf(updatedUser.getUserName())); if (databaseUser.isEmpty()) { // 如果未找到，抛出异常 throw new UserNotFoundException("User with the this id is not found"); } // 映射DTO到实体，并保存 UserEntity entity = mapToUserEntity(updatedUser); return map(userRepository.save(entity));}
此方法首先尝试通过userRepository.findById()查找现有用户。如果返回的Optional为空（即isEmpty()为true），则抛出UserNotFoundException。
单元测试中的陷阱：Mockito的默认行为
当我们在单元测试中对userService进行测试时，userRepository通常会被mock。例如，一个尝试测试updateUser方法的测试用例可能如下：
@Testvoid updateUserTest(){ final int id = 1; final long roleId = 2L; UserDTO userDto = new UserDTO(); userDto.setUserName(String.valueOf(12)); // 用于findById的查找ID userDto.setId(String.valueOf(id)); // ... 其他属性设置 // 模拟roleRepository，与当前问题无关 when(roleRepository.findById(any())).thenReturn(Optional.of(new UserDTO().setId(roleId))); // 将DTO映射为实体，此实体通常是更新后的状态 UserEntity userEntity = userService.mapToUserEntity(userDto); // 模拟userRepository.save()方法 when(userRepository.save(any())).thenReturn(userEntity.setId(id)); // 调用待测试方法 var actualUser = userService.updateUser(String.valueOf(id), userDto); // 断言 // userDto.setUserName(String.valueOf(id)); // 此行可能导致混淆，应删除或提前处理 assertEquals(actualUser, userDto);}
上述测试代码的问题在于，它模拟了roleRepository.findById()和userRepository.save()，但没有模拟userRepository.findById()方法。
Mockito在遇到未明确stubbing的方法时，会根据其返回类型提供默认值。对于返回Optional类型的方法，Mockito的默认答案行为（RETURNS_DEFAULTS）是返回一个空的Optional。这意味着，当userService.updateUser方法调用userRepository.findById(Integer.valueOf(updatedUser.getUserName()))时，由于userRepository是一个mock对象且该方法未被stubbing，它会默认返回Optional.empty()。
于是，服务层中的if (databaseUser.isEmpty())条件将为true，导致UserNotFoundException被抛出，测试失败。
解决方案：显式Stubbing findById方法
为了解决这个问题，我们需要显式地stubbing userRepository.findById()方法，使其返回一个非空的Optional，其中包含一个模拟的UserEntity对象，以模拟找到用户的情况。
根据服务层代码，findById方法会使用updatedUser.getUserName()的值作为查找ID。在我们的测试中，userDto.setUserName(String.valueOf(12))，因此findById会被调用时传入12。
正确的stubbing应该如下：
// 模拟userRepository.findById(12)方法，使其返回一个包含userEntity的Optionalwhen(userRepository.findById(12)).thenReturn(Optional.of(userEntity));// 模拟userRepository.save()方法when(userRepository.save(any())).thenReturn(userEntity.setId(id));// 调用待测试方法userService.updateUser(String.valueOf(id), userDto); // 第一次调用，触发findById和savevar actualUser = userService.updateUser(String.valueOf(id), userDto); // 第二次调用，获取返回值进行断言
注意： 在原始问题中，userService.updateUser被调用了两次。通常，一次调用足以触发被测逻辑并获取返回值进行断言。如果第二次调用是预期行为，请确保其参数和stubbing与第一次调用一致。为了测试简洁性，我们通常只调用一次并捕获返回值。
修正后的完整测试代码
以下是修正后的updateUserTest方法，它包含了对userRepository.findById()的正确stubbing：
import org.junit.jupiter.api.BeforeEach;import org.junit.jupiter.api.Test;import org.mockito.InjectMocks;import org.mockito.Mock;import org.mockito.MockitoAnnotations;import java.time.LocalDateTime;import java.util.List;import java.util.Optional;import static org.junit.jupiter.api.Assertions.assertEquals;import static org.mockito.ArgumentMatchers.any;import static org.mockito.Mockito.when;// 假设UserDTO, UserEntity, UserService, UserRepository, RoleRepository已定义// 并且UserDTO.Name, UserDTO.Email是嵌套类// UserNotFoundException是自定义异常class UserServiceTest { @Mock private UserRepository userRepository; @Mock private RoleRepository roleRepository; // 假设存在 @InjectMocks private UserService userService; // 假设UserService中包含mapToUserEntity方法 @BeforeEach void setUp() { MockitoAnnotations.openMocks(this); // 通常在这里进行一些公共的初始化或mock行为设置 } @Test void updateUserTest(){ final int id = 1; final long roleId = 2L; // 示例角色ID UserDTO userDto = new UserDTO(); userDto.setUserName(String.valueOf(12)); // userName用于findById的查找 userDto.setId(String.valueOf(id)); // DTO本身的ID userDto.setName(new UserDTO.Name("surname", "firstname", "patronymic")); userDto.setActive(true); userDto.setEmails(List.of(new UserDTO.Email("email@example.com", "external"))); userDto.setRoles(List.of("2")); // 示例角色ID userDto.setLastAccessDate(LocalDateTime.of(2022, 10, 25, 4, 20)); userDto.setUnit(null); // 示例null值 // 模拟roleRepository，如果updateUser方法依赖于此 when(roleRepository.findById(any())).thenReturn(Optional.of(new UserDTO().setId(roleId))); // 创建一个UserEntity，用于模拟findById和save的返回值 // 这个userEntity通常代表了更新前的或期望更新后的实体状态 UserEntity userEntity = userService.mapToUserEntity(userDto); // 对于findById，它应该返回一个“找到的”实体，这里我们使用userEntity作为示例 // 实际上，findById应该返回一个“现有”实体，save会接收一个“更新后”的实体。 // 为了简化和解决当前问题，我们让findById返回这个userEntity。 userEntity.setId(Integer.valueOf(userDto.getId())); // 确保实体ID与DTO ID一致 // 核心修正：模拟userRepository.findById()方法，使其返回非空Optional // findById的参数是Integer.valueOf(updatedUser.getUserName())，即12 when(userRepository.findById(12)).thenReturn(Optional.of(userEntity)); // 模拟userRepository.save()方法，使其返回保存后的实体 // save方法的参数是any()，因为我们不关心具体传入的实例，只关心返回值 when(userRepository.save(any(UserEntity.class))).thenReturn(userEntity); // save通常返回保存后的实体 // 调用待测试方法，只调用一次并获取结果 UserDTO actualUser = userService.updateUser(String.valueOf(id), userDto); // 断言：验证返回的DTO是否符合预期 assertEquals(userDto, actualUser); }}
注意事项：
Stubbing完整性： 确保所有被测方法依赖的外部方法（如userRepository.findById()和userRepository.save()）都被正确stubbing。参数匹配： when()语句中的参数应与实际调用时传入的参数匹配。如果参数不确定，可以使用any()、anyInt()等Mockito匹配器。返回类型匹配： thenReturn()中的值类型必须与被stubbing方法的返回类型匹配。对于Optional，需要返回Optional.of(T)或Optional.empty()。mapToUserEntity的调用： 在测试中，userService.mapToUserEntity(userDto)的调用是为了准备一个UserEntity实例，用于findById和save的stubbing。确保这个userEntity能够代表你期望的模拟数据。测试的简洁性： 避免不必要的重复调用被测方法，一次调用并捕获结果进行断言通常足够。
总结
在Mockito单元测试中，当被测代码依赖于返回Optional类型的方法（如Repository.findById()）时，务必显式地对其进行stubbing。Mockito的默认行为是为Optional返回Optional.empty()，这常常会导致服务层中对Optional.isEmpty()的检查通过，进而触发异常。通过when(mockObject.method(args)).thenReturn(Optional.of(expectedValue))来模拟成功查找的情况，可以确保测试流程按预期执行，从而专注于测试服务层的业务逻辑，而不是底层依赖的默认行为。理解并正确运用Mockito的stubbing机制是编写健壮、可靠单元测试的关键。
以上就是Mockito测试中Optional类型返回值默认行为与正确Stubbing实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/130855.html
微信扫一扫 
支付宝扫一扫 
