在开发基于Spring Boot等框架的应用时，服务层通常会与数据访问层（Repository）交互。当服务层方法需要根据ID查询实体时，常见的模式是使用Optional来处理查找结果，并根据Optional是否为空来决定后续操作，例如抛出“未找到”异常。然而，在编写单元测试时，如果对Repository的findById等方法没有进行适当的stubbing（模拟），Mockito的默认行为可能会导致测试失败。
问题分析：服务层与Repository交互
考虑以下服务层中的updateUser方法：
@Override
public 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方法的测试用例可能如下：
@Test
void 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的Optional when(userRepository.findById(12)).thenReturn(Optional.of(userEntity)); // 模拟userRepository.save()方法 when(userRepository.save(any())).thenReturn(userEntity.setId(id)); // 调用待测试方法 userService.updateUser(String.valueOf(id), userDto); // 第一次调用，触发findById和save var 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机制是编写健壮、可靠单元测试的关键。
