
在开发基于Spring Boot等框架的应用时,服务层通常会与数据访问层(Repository)交互。当服务层方法需要根据ID查询实体时,常见的模式是使用Optional来处理查找结果,并根据Optional是否为空来决定后续操作,例如抛出“未找到”异常。然而,在编写单元测试时,如果对Repository的findById等方法没有进行适当的stubbing(模拟),Mockito的默认行为可能会导致测试失败。
考虑以下服务层中的updateUser方法:
@Override
public UserDTO updateUser(String id, UserDTO updatedUser) {
// 根据updatedUser的userName字段查找用户
Optional<UserEntity> 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。
当我们在单元测试中对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 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);
}
}注意事项:
在Mockito单元测试中,当被测代码依赖于返回Optional类型的方法(如Repository.findById())时,务必显式地对其进行stubbing。Mockito的默认行为是为Optional返回Optional.empty(),这常常会导致服务层中对Optional.isEmpty()的检查通过,进而触发异常。通过when(mockObject.method(args)).thenReturn(Optional.of(expectedValue))来模拟成功查找的情况,可以确保测试流程按预期执行,从而专注于测试服务层的业务逻辑,而不是底层依赖的默认行为。理解并正确运用Mockito的stubbing机制是编写健壮、可靠单元测试的关键。
以上就是Mockito测试中Optional类型返回值默认行为与正确Stubbing实践的详细内容,更多请关注php中文网其它相关文章!
Microsoft Bing是一款可帮助您快速找到值得信赖的搜索结果,跟踪您关注的话题和热门故事,并让您控制 自己的隐私。无需输入,只需使用语音、相机或网络图片进行搜索即可。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号