
在开发基于Spring Boot等框架的应用时,服务层(Service Layer)通常会与数据访问层(Repository Layer)进行交互。当对服务层方法进行单元测试时,我们通常会使用Mockito等框架来模拟(Mock)Repository的行为,以隔离测试范围,确保只测试服务层自身的逻辑。
一个常见的问题场景是,当服务层中的更新方法(例如updateUser)首先通过Repository的findById方法查询现有数据,然后根据查询结果进行后续操作时,单元测试可能会失败并抛出UserNotFoundException。
考虑以下服务层updateUser方法的简化实现:
@Override
public UserDTO updateUser(String id, UserDTO updatedUser) {
// 1. 通过 updatedUser 的 userName 字段查找用户
Optional<UserEntity> databaseUser = userRepository.findById(Integer.valueOf(updatedUser.getUserName()));
// 2. 如果未找到用户,则抛出异常
if (databaseUser.isEmpty()) {
throw new UserNotFoundException("User with the this id is not found");
}
// 3. 将更新后的 DTO 映射为实体
UserEntity entity = mapToUserEntity(updatedUser);
// 4. 保存更新后的实体
return map(userRepository.save(entity));
}在上述方法中,userRepository.findById()的返回值是一个Optional<UserEntity>。如果这个Optional是空的(isEmpty()为true),则会抛出UserNotFoundException。
现在,让我们看看一个可能导致此问题的单元测试:
@Test
void updateUserTest(){
final int id = 1;
final int userNameAsId = 12; // 假设 updatedUser.userName 会被解析为 12
UserDTO userDto = new UserDTO();
userDto.setUserName(String.valueOf(userNameAsId)); // 此值将用于 findById
// ... 其他 userDto 字段的设置 ...
// 模拟 roleRepository,与当前问题无关
when(roleRepository.findById(any())).thenReturn(Optional.of(new UserDTO().setId(2L)));
// 将 userDto 映射为 UserEntity,此实体将用于 save 方法
UserEntity userEntity = userService.mapToUserEntity(userDto);
// 模拟 userRepository.save 方法
when(userRepository.save(any())).thenReturn(userEntity.setId(id));
// 调用被测试的服务方法
userService.updateUser(String.valueOf(id), userDto); // 第一次调用
var actualUser = userService.updateUser(String.valueOf(id), userDto); // 第二次调用
// ... 断言 ...
}在这个测试中,问题在于 userRepository.findById() 方法没有被显式地模拟。当Mockito遇到一个未被模拟的方法调用时,它会使用其默认行为(RETURNS_DEFAULTS)。对于返回Optional类型的方法,Mockito的默认行为是返回一个空的Optional(即Optional.empty())。因此,当updateUser方法中的userRepository.findById(Integer.valueOf(updatedUser.getUserName()))被调用时,它将返回Optional.empty(),从而触发databaseUser.isEmpty()为true,最终导致UserNotFoundException被抛出,测试失败。
要解决这个问题,我们需要在调用被测试的服务方法之前,明确地模拟userRepository.findById()的行为,使其返回一个包含有效UserEntity的Optional。
以下是修正后的测试代码片段,突出显示了关键的模拟部分:
@Test
void updateUserTestCorrected() {
final int id = 1;
final int userNameForLookup = 12; // 这个值是 updateUser 方法中 findById 的参数来源
UserDTO userDto = new UserDTO();
userDto.setUserName(String.valueOf(userNameForLookup)); // 确保 DTO 中的 userName 与查找逻辑匹配
userDto.setId(String.valueOf(id));
userDto.setName(new UserDTO.Name("surname", "firstname", "patronymic"));
userDto.setActive(true);
// ... 其他 userDto 字段的设置 ...
// 1. 模拟 userRepository.findById 方法
// findById 会被调用参数为 userNameForLookup (即 12)
// 我们应该返回一个包含现有 UserEntity 的 Optional
UserEntity existingUserEntity = new UserEntity();
existingUserEntity.setId(userNameForLookup); // 设置一个 ID,表示这是数据库中已存在的用户
existingUserEntity.setName(new UserEntity.Name("oldSurname", "oldFirstname", "oldPatronymic"));
// ... 根据需要设置 existingUserEntity 的其他字段 ...
when(userRepository.findById(userNameForLookup)).thenReturn(Optional.of(existingUserEntity));
// 2. 模拟 userRepository.save 方法
// 这个实体是从 userDto 映射而来,是 save 方法的期望入参
UserEntity entityToSave = userService.mapToUserEntity(userDto);
entityToSave.setId(id); // 确保保存后返回的实体 ID 正确
when(userRepository.save(any(UserEntity.class))).thenReturn(entityToSave);
// 3. 调用被测试的服务方法
UserDTO actualUser = userService.updateUser(String.valueOf(id), userDto);
// 4. 断言验证
// 确保实际返回的用户数据与预期一致
// 注意:原始测试中对 userDto.setUserName(String.valueOf(id)); 的操作应在断言前完成,
// 或确保 userDto 在测试开始时就完全代表期望的最终状态。
// 这里我们直接比较 actualUser 和 userDto 的关键属性。
assertEquals(userDto.getUserName(), actualUser.getUserName());
assertEquals(userDto.getName().getFirstName(), actualUser.getName().getFirstName());
assertEquals(userDto.getId(), actualUser.getId());
// ... 更多详细断言 ...
}通过添加 when(userRepository.findById(userNameForLookup)).thenReturn(Optional.of(existingUserEntity)); 这一行,我们明确告诉Mockito:当userRepository.findById(12)被调用时,返回一个包含existingUserEntity的Optional,从而避免了Optional.empty()的默认行为,使服务层的isEmpty()检查通过。
Mockito默认行为的理解 Mockito在没有明确模拟的情况下,对于不同返回类型的方法有不同的默认行为:
模拟的完整性与时序 在单元测试中,模拟所有被测方法所依赖的外部协作对象(Mocks)的行为是关键。确保在调用被测方法(即测试的“执行”阶段)之前,所有相关的模拟都已设置完毕。例如,findById的模拟必须在userService.updateUser被调用之前完成。
模拟数据的匹配与上下文
测试断言的重要性 一个完整的单元测试不仅要执行代码,更要验证其行为和结果。在updateUserTestCorrected示例中,我们不仅解决了UserNotFoundException,还增加了assertEquals来验证updateUser方法是否返回了预期的UserDTO,以及其内部的字段是否正确更新。这确保了我们不仅测试了代码的执行路径,还测试了其功能正确性。
在Mockito单元测试中,当服务层方法依赖于Repository返回Optional类型的数据时,务必注意显式模拟findById等方法,以避免因Mockito默认返回Optional.empty()而导致的业务逻辑异常。通过清晰地模拟所有外部依赖的行为,并结合对Mockito默认行为的理解,我们可以编写出更稳定、更可靠的服务层单元测试,从而有效提升代码质量。
以上就是Mockito测试中服务层更新方法:正确模拟Repository行为的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号