本文探讨了在M%ignore_a_1%ckito单元测试中，当服务层方法依赖于Repository的findById方法返回Optional时，可能遇到的UserNotFoundException问题。核心原因是findById方法未被正确模拟，导致Mockito默认返回Optional.empty()。文章提供了详细的解决方案，即通过when().thenReturn()明确模拟findById的返回值，并讨论了Mockito的默认行为、测试时序以及数据模拟的注意事项，旨在帮助开发者编写更健壮的服务层单元测试。
问题剖析：Optional.isEmpty()引发的异常
在开发基于Spring Boot等框架的应用时，服务层（Service Layer）通常会与数据访问层（Repository Layer）进行交互。当对服务层方法进行单元测试时，我们通常会使用Mockito等框架来模拟（Mock）Repository的行为，以隔离测试范围，确保只测试服务层自身的逻辑。
一个常见的问题场景是，当服务层中的更新方法（例如updateUser）首先通过Repository的findById方法查询现有数据，然后根据查询结果进行后续操作时，单元测试可能会失败并抛出UserNotFoundException。
考虑以下服务层updateUser方法的简化实现：
@Overridepublic 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。如果这个Optional是空的（isEmpty()为true），则会抛出UserNotFoundException。
现在，让我们看看一个可能导致此问题的单元测试：
@Testvoid 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。
以下是修正后的测试代码片段，突出显示了关键的模拟部分：
@Testvoid 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默认行为的理解，我们可以编写出更稳定、更可靠的服务层单元测试，从而有效提升代码质量。
以上就是Mockito测试中服务层更新方法：正确模拟Repository行为的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/130938.html
微信扫一扫 
支付宝扫一扫 
