Mockito中Optional默认行为解析

对于一个文章开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《Mockito中Optional默认行为与正确stub方法》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

本文旨在解决在使用Mockito进行单元测试时，服务层方法中对Optional类型返回值（如userRepository.findById()）进行isEmpty()检查时，因未正确stubbing导致默认返回空Optional，进而抛出NotFoundException的问题。我们将详细分析Mockito的默认行为，并提供正确的stubbing策略，确保测试流程按预期执行。

在开发基于Spring Boot等框架的应用时，服务层通常会与数据访问层（Repository）交互。当服务层方法需要根据ID查询实体时，常见的模式是使用Optional来处理查找结果，并根据Optional是否为空来决定后续操作，例如抛出“未找到”异常。然而，在编写单元测试时，如果对Repository的findById等方法没有进行适当的stubbing（模拟），Mockito的默认行为可能会导致测试失败。

问题分析：服务层与Repository交互

考虑以下服务层中的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。

单元测试中的陷阱：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);
    }
}

注意事项：

1. Stubbing完整性： 确保所有被测方法依赖的外部方法（如userRepository.findById()和userRepository.save()）都被正确stubbing。
2. 参数匹配： when()语句中的参数应与实际调用时传入的参数匹配。如果参数不确定，可以使用any()、anyInt()等Mockito匹配器。
3. 返回类型匹配： thenReturn()中的值类型必须与被stubbing方法的返回类型匹配。对于Optional，需要返回Optional.of(T)或Optional.empty()。
4. mapToUserEntity的调用： 在测试中，userService.mapToUserEntity(userDto)的调用是为了准备一个UserEntity实例，用于findById和save的stubbing。确保这个userEntity能够代表你期望的模拟数据。
5. 测试的简洁性： 避免不必要的重复调用被测方法，一次调用并捕获结果进行断言通常足够。

总结

在Mockito单元测试中，当被测代码依赖于返回Optional类型的方法（如Repository.findById()）时，务必显式地对其进行stubbing。Mockito的默认行为是为Optional返回Optional.empty()，这常常会导致服务层中对Optional.isEmpty()的检查通过，进而触发异常。通过when(mockObject.method(args)).thenReturn(Optional.of(expectedValue))来模拟成功查找的情况，可以确保测试流程按预期执行，从而专注于测试服务层的业务逻辑，而不是底层依赖的默认行为。理解并正确运用Mockito的stubbing机制是编写健壮、可靠单元测试的关键。

到这里，我们也就讲完了《Mockito中Optional默认行为解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！