问题剖析：Optional.isEmpty()引发的异常
在开发基于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 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
现在，让我们看看一个可能导致此问题的单元测试：
@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在没有明确模拟的情况下，对于不同返回类型的方法有不同的默认行为：
- 原始类型（如int, boolean）： 返回其类型的默认值（0, false）。
- 集合类型（如List, Set, Map）： 返回空集合。
- Optional类型： 返回Optional.empty()。
- 对象类型： 返回null。 了解这些默认行为对于编写健壮的测试至关重要，它可以帮助我们预判哪些方法需要被显式模拟。
模拟的完整性与时序 在单元测试中，模拟所有被测方法所依赖的外部协作对象（Mocks）的行为是关键。确保在调用被测方法（即测试的“执行”阶段）之前，所有相关的模拟都已设置完毕。例如，findById的模拟必须在userService.updateUser被调用之前完成。
-
模拟数据的匹配与上下文
- findById的模拟： findById通常用于模拟从数据库中“读取”现有数据。因此，返回的UserEntity应该代表一个“已存在”的用户。它的ID应该与服务方法中用于查找的ID参数匹配。
- save的模拟： save方法通常用于模拟数据更新或插入。它的入参是服务层准备好的实体，返回的是“保存后”的实体（通常是同一个实体，可能带有数据库生成的ID）。 在实际测试中，确保模拟返回的数据能够满足后续业务逻辑的需要，例如，如果后续逻辑会访问existingUserEntity的某个字段，那么模拟时就需要确保该字段有值。
测试断言的重要性 一个完整的单元测试不仅要执行代码，更要验证其行为和结果。在updateUserTestCorrected示例中，我们不仅解决了UserNotFoundException，还增加了assertEquals来验证updateUser方法是否返回了预期的UserDTO，以及其内部的字段是否正确更新。这确保了我们不仅测试了代码的执行路径，还测试了其功能正确性。
总结
在Mockito单元测试中，当服务层方法依赖于Repository返回Optional类型的数据时，务必注意显式模拟findById等方法，以避免因Mockito默认返回Optional.empty()而导致的业务逻辑异常。通过清晰地模拟所有外部依赖的行为，并结合对Mockito默认行为的理解，我们可以编写出更稳定、更可靠的服务层单元测试，从而有效提升代码质量。
