当前位置:

首页 > 编程开发 > Mockito模拟Optional返回值技巧

Mockito模拟Optional返回值技巧

本文探讨了在使用Mockito对Java服务层方法进行单元测试时,因未正确模拟Optional类型返回值而导致业务异常的问题。通过分析Mockito的默认行为,本文详细解释了为何findById等方法会返回空Optional,并提供了明确的解决方案:通过when().thenReturn()显式地stubOptional返回值,确保测试流程按预期执行,从而避免“用户未找到”等业务异常,提升测试的准确性和可靠性。

Mockito单元测试:正确模拟Optional返回值以避免业务异常

本文探讨了在使用Mockito对Java服务层方法进行单元测试时,因未正确模拟Optional类型返回值而导致业务异常的问题。通过分析Mockito的默认行为,本文详细解释了为何findById等方法会返回空Optional,并提供了明确的解决方案:通过when().thenReturn()显式地stub Optional返回值,确保测试流程按预期执行,从而避免“用户未找到”等业务异常,提升测试的准确性和可靠性。

问题分析:Mockito与Optional的默认行为

在进行单元测试时,我们通常会使用Mocking框架(如Mockito)来隔离被测试单元(System Under Test, SUT)与外部依赖,确保测试的焦点仅在于SUT本身的逻辑。然而,当依赖的方法返回Optional类型时,如果不进行适当的模拟,可能会遇到意料之外的行为。

考虑以下服务层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()查询用户是否存在,如果不存在则抛出UserNotFoundException。

在编写updateUser方法的单元测试时,我们可能会遇到“User with the this id is not found”的异常,即使我们预期用户是存在的。这是因为Mockito在模拟对象时,对于返回复杂类型(如Optional、集合、自定义对象等)的方法,如果没有明确指定其行为,它会返回其类型的默认值。对于Optional,其默认值是Optional.empty()。

原始测试代码片段如下:

@Test
void updateUserTest(){
    // ... 用户DTO数据准备 ...

    // 模拟roleRepository.findById的行为
    when(roleRepository.findById(any())).thenReturn(Optional.of(new UserDTO().setId(roleId)));

    // 将userDto映射为UserEntity
    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()方法并没有被显式地模拟(stub)。因此,当updateUser方法内部调用userRepository.findById(Integer.valueOf(updatedUser.getUserName()))时,Mockito会返回Optional.empty()。这导致databaseUser.isEmpty()判断为真,进而触发UserNotFoundException。

解决方案:显式Stubbing Optional返回值

要解决这个问题,核心在于明确告诉Mockito,当userRepository.findById()被调用时,它应该返回一个包含预期UserEntity的Optional对象,而不是默认的空Optional。

我们需要在调用userService.updateUser之前,添加对userRepository.findById的模拟。模拟时需要注意findById的参数类型,它接收一个Integer类型的ID。在我们的userDto中,userName被设置为"12",因此Integer.valueOf(updatedUser.getUserName())会是12。

以下是正确的模拟方式:

// 1. 准备一个预期由findById返回的UserEntity实例
// 这个实例应该代表数据库中已存在的用户
UserEntity existingUserEntity = new UserEntity(); // 实际项目中应根据需要填充数据
existingUserEntity.setId(Integer.valueOf(userDto.getUserName())); // 确保ID与查询匹配
// ... 填充existingUserEntity的其他属性 ...

// 2. 模拟userRepository.findById的行为,使其返回包含existingUserEntity的Optional
when(userRepository.findById(Integer.valueOf(userDto.getUserName())))
    .thenReturn(Optional.of(existingUserEntity));

// 3. 模拟userRepository.save的行为(如果尚未模拟)
// 注意:userEntity是userService.mapToUserEntity(userDto)的结果,是将被保存的实体
UserEntity mappedUserEntity = userService.mapToUserEntity(userDto);
when(userRepository.save(any(UserEntity.class))).thenReturn(mappedUserEntity);

通过以上修改,当updateUser方法内部调用userRepository.findById(12)时,它将收到一个非空的Optional,从而跳过isEmpty()检查并继续执行后续的更新逻辑。

完整测试代码示例

为了提供一个更清晰、完整的测试示例,我们将整合上述修改,并对原始测试进行一些优化,例如避免重复调用被测方法。

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.junit.jupiter.api.Assertions.assertNotNull;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.when;
import static org.mockito.Mockito.verify;

// 假设这些是你的Service, Repository和DTO类
// import com.example.service.UserService;
// import com.example.repository.UserRepository;
// import com.example.repository.RoleRepository;
// import com.example.dto.UserDTO;
// import com.example.entity.UserEntity;
// import com.example.exception.UserNotFoundException;

class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @Mock
    private RoleRepository roleRepository;

    @InjectMocks
    private UserService userService; // 假设UserService中包含mapToUserEntity和map方法

    @BeforeEach
    void setUp() {
        MockitoAnnotations.openMocks(this);
        // 如果UserService依赖于其他Service或组件,也需要在这里Mock并注入
        // 例如:userService = new UserService(userRepository, roleRepository, ...);
        // 或者使用 @Spy 来部分Mock真实对象
    }

    @Test
    void updateUser_shouldUpdateExistingUserSuccessfully() {
        // 1. 准备测试数据
        final int userId = 12; // 对应updatedUser.getUserName()
        final long roleId = 2L;

        UserDTO userDto = new UserDTO();
        userDto.setUserName(String.valueOf(userId)); // 用于findById的ID
        userDto.setId(String.valueOf(1)); // 外部传入的ID,通常与userName对应的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(String.valueOf(roleId)));
        userDto.setLastAccessDate(LocalDateTime.of(2022, 10, 25, 4, 20));
        userDto.setUnit(null);

        // 2. 模拟依赖行为

        // 模拟 userRepository.findById() 返回一个已存在的UserEntity
        UserEntity existingUserEntity = new UserEntity();
        existingUserEntity.setId(userId); // 确保ID匹配
        existingUserEntity.setUserName(String.valueOf(userId));
        // ... 填充 existingUserEntity 的其他必要属性,使其在业务逻辑中有效 ...
        when(userRepository.findById(userId)).thenReturn(Optional.of(existingUserEntity));

        // 模拟 userService.mapToUserEntity() 的结果 (如果该方法是SUT的一部分,则不需要Mock)
        // 假设userService.mapToUserEntity是userService内部方法,直接调用即可
        UserEntity mappedUserEntity = userService.mapToUserEntity(userDto);
        // 如果mapToUserEntity是私有方法或难以直接调用,可以考虑Mock UserService本身或使用ArgumentCaptor

        // 模拟 userRepository.save() 返回保存后的UserEntity
        // 注意:这里返回的mappedUserEntity是期望被保存的实体,可能带上更新后的ID或版本
        when(userRepository.save(any(UserEntity.class))).thenReturn(mappedUserEntity);

        // 模拟 roleRepository.findById()
        when(roleRepository.findById(any())).thenReturn(Optional.of(new Object())); // 假设返回任意非空对象即可

        // 3. 调用被测方法
        UserDTO actualUserDto = userService.updateUser(String.valueOf(userDto.getId()), userDto);

        // 4. 验证结果
        assertNotNull(actualUserDto);
        // 验证返回的DTO是否符合预期,这里可以根据具体业务逻辑进行更细致的断言
        // 例如:assertEquals(userDto.getName().getFirstName(), actualUserDto.getName().getFirstName());
        // 如果userService.map方法会改变DTO,则不能直接比较userDto和actualUserDto
        // 简单起见,这里假设它们是等价的,或者至少某些关键属性是等价的
        assertEquals(userDto.getUserName(), actualUserDto.getUserName());
        assertEquals(userDto.getEmails().get(0).getValue(), actualUserDto.getEmails().get(0).getValue());

        // 验证 userRepository.findById 和 userRepository.save 是否被调用
        verify(userRepository).findById(userId);
        verify(userRepository).save(any(UserEntity.class));
    }

    // 假设UserService中存在这些辅助方法用于测试
    // 实际项目中,这些方法可能在UserService内部或独立的Mapper类中
    private static class UserService {
        private UserRepository userRepository;
        private RoleRepository roleRepository;

        // 构造函数用于注入Mock
        public UserService(UserRepository userRepository, RoleRepository roleRepository) {
            this.userRepository = userRepository;
            this.roleRepository = roleRepository;
        }

        // 模拟的mapToUserEntity方法
        public UserEntity mapToUserEntity(UserDTO dto) {
            UserEntity entity = new UserEntity();
            entity.setId(Integer.valueOf(dto.getUserName())); // 假设userName是ID
            entity.setFirstName(dto.getName().getFirstName());
            entity.setLastName(dto.getName().getLastName());
            entity.setEmail(dto.getEmails().get(0).getValue());
            entity.setActive(dto.isActive());
            entity.setLastAccessDate(dto.getLastAccessDate());
            // ... 其他属性映射 ...
            return entity;
        }

        // 模拟的map方法
        public UserDTO map(UserEntity entity) {
            UserDTO dto = new UserDTO();
            dto.setId(String.valueOf(entity.getId()));
            dto.setUserName(String.valueOf(entity.getId())); // 假设userName和ID一致
            dto.setName(new UserDTO.Name(entity.getLastName(), entity.getFirstName(), ""));
            dto.setActive(entity.isActive());
            dto.setEmails(List.of(new UserDTO.Email(entity.getEmail(), "external")));
            dto.setLastAccessDate(entity.getLastAccessDate());
            // ... 其他属性映射 ...
            return dto;
        }

        // 实际的updateUser方法,与问题描述中相同
        public UserDTO updateUser(String id, UserDTO updatedUser) {
            Optional databaseUser = userRepository.findById(Integer.valueOf(updatedUser.getUserName()));
            if (databaseUser.isEmpty()) {
                throw new UserNotFoundException("User with the this id is not found");
            }
            UserEntity entity = mapToUserEntity(updatedUser);
            return map(userRepository.save(entity));
        }
    }

    // 模拟的UserDTO类及其内部类
    private static class UserDTO {
        private String id;
        private String userName;
        private Name name;
        private boolean active;
        private List emails;
        private List roles;
        private LocalDateTime lastAccessDate;
        private Object unit; // 假设unit是Object类型

        // Getters and Setters
        public String getId() { return id; }
        public UserDTO setId(String id) { this.id = id; return this; }
        public String getUserName() { return userName; }
        public void setUserName(String userName) { this.userName = userName; }
        public Name getName() { return name; }
        public void setName(Name name) { this.name = name; }
        public boolean isActive() { return active; }
        public void setActive(boolean active) { this.active = active; }
        public List getEmails() { return emails; }
        public void setEmails(List emails) { this.emails = emails; }
        public List getRoles() { return roles; }
        public void setRoles(List roles) { this.roles = roles; }
        public LocalDateTime getLastAccessDate() { return lastAccessDate; }
        public void setLastAccessDate(LocalDateTime lastAccessDate) { this.lastAccessDate = lastAccessDate; }
        public Object getUnit() { return unit; }
        public void setUnit(Object unit) { this.unit = unit; }

        public static class Name {
            private String surname;
            private String firstname;
本文内容来源于互联网,如有侵权请联系删除。
作者最新文章
编程开发
相关文章 更多
using namespace 使用中遇到的问题怎么解决
using namespace 使用中遇到的问题怎么解决

命名空间的基本概念与常见引入问题在C++等编程语言中,命名空间(namespace)是一种将代码标识符(如变量、函数、类名)封装在特定名称下的机制,其主要目的是避免命名冲突,尤其是在大型项目或使用多个第三方库时。使用“using namespace”指令可以将指定命名空间中的所有名称引入当前作用域,

c语言函数递归 实操经验总结:这些技巧很实用
c语言函数递归 实操经验总结:这些技巧很实用

理解递归的基本原理在C语言中,递归是一种函数调用自身的编程技术。要掌握它,首先需要理解其核心思想:将一个复杂的大问题,分解为一个或几个与原问题相似但规模更小的子问题,直到子问题足够简单,可以直接求解。这个过程通常包含两个关键部分:递归出口和递归体。递归出口定义了问题何时不再继续分解,即最简单、可直接

c语言函数递归 怎么选?常见方案对比分析
c语言函数递归 怎么选?常见方案对比分析

递归函数的基本概念与适用场景在C语言编程中,递归是一种函数调用自身的编程技巧。它并非适用于所有问题,但在处理某些具有自相似结构的问题时,能提供极其清晰和优雅的解决方案。递归的核心思想是将一个大规模问题分解为一个或多个同类型但规模更小的子问题,直到子问题简单到可以直接求解。典型的适用场景包括树形结构的

Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解
Objective-C 内存管理入门:从 alloc 到 dealloc 的生命周期详解

理解内存管理的基石在Objective-C的编程世界中,内存管理是开发者必须掌握的核心技能之一。它直接关系到应用的性能、稳定性与资源利用效率。与一些采用自动垃圾回收机制的语言不同,Objective-C在很长一段时间里,依赖一套基于引用计数的、需要开发者部分介入的管理规则。这套规则的核心思想是明确的

如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏
如何正确使用 dealloc 以避免 iOS 应用中的内存泄漏

理解 dealloc 的角色与时机在 iOS 应用开发中,内存管理是保障应用性能与稳定性的基石。dealloc 方法是 Objective-C 中对象生命周期结束时的关键回调,它标志着对象即将被系统回收内存。正确理解其触发时机至关重要:当一个对象的引用计数降为零时,运行时系统会自动调用该对象的 de

深入理解 Objective-C 中的 dealloc 方法:内存管理核心机制
深入理解 Objective-C 中的 dealloc 方法:内存管理核心机制

内存管理的基石在Objective-C的世界里,内存管理是开发者必须掌握的核心技能之一。作为一门在手动引用计数(MRC)时代诞生的语言,Objective-C要求程序员对对象的生命周期有清晰的认识。dealloc方法正是这一生命周期中至关重要的终点站。它是一个实例方法,当对象的引用计数降为零时,系统

理解 native2ascii:Java 国际化开发中的字符编码工具
理解 native2ascii:Java 国际化开发中的字符编码工具

native2ascii 工具的基本定位在Ja va应用程序的国际化与本地化开发过程中,处理非拉丁字符集是一个常见且关键的环节。Ja va内部使用Unicode字符集来统一表示全球各种语言的文字,但其属性文件(.properties)在历史上要求使用ASCII编码,或者更准确地说,要求非ASCII字

如何使用 native2ascii 转换中文字符为 Unicode 转义序列
如何使用 native2ascii 转换中文字符为 Unicode 转义序列

理解 native2ascii 工具的基本用途在软件开发,特别是涉及国际化处理的场景中,开发者常常需要处理不同编码的文本资源。native2ascii 是 Ja va 开发工具包(JDK)中提供的一个命令行实用程序,其主要功能是将包含本地字符编码(非ASCII字符)的文件,转换为包含 Unicode

Java native2ascii 命令详解:解决属性文件乱码问题
Java native2ascii 命令详解:解决属性文件乱码问题

native2ascii 命令的由来与作用在Ja va开发中,处理国际化资源文件是一个常见需求。资源文件通常以.properties格式存储,用于支持多语言界面。然而,Ja va属性文件默认采用ISO-8859-1字符集编码,这导致了一个直接的问题:当文件中包含非拉丁字符(如中文、日文、韩文等)时,

一个 memwatch 实战案例:定位野指针问题
一个 memwatch 实战案例:定位野指针问题

内存监控工具的价值与挑战在软件开发,尤其是使用C/C++这类手动管理内存的语言时,内存错误是程序员最常遭遇的难题之一。其中,野指针问题因其隐蔽性和破坏性,往往成为最难定位的“幽灵”缺陷。它可能潜伏在代码中,在特定条件下才被触发,导致程序崩溃、数据损坏或难以预测的行为。传统的调试手段,如打印日志或使用

查看更多
精品专题 更多
装机必备
装机必备

正软商城装机必备专区,精选办公、浏览器、安全防护、影音播放、压缩解压、设计创作和系统工具等电脑常用正版软件,帮助用户快速完成新电脑软件配置。

Windows
Windows

正软商城Windows软件专区,汇集适用于Windows电脑的办公、设计、安全防护、影音播放、开发工具和系统优化软件,提供软件介绍、系统要求、正版授权及购买下载服务。

macOS软件
macOS软件

正软商城macOS软件专区,精选适用于Mac电脑的办公、设计、影音、效率、开发和系统工具,提供软件功能介绍、macOS兼容版本、正版授权及购买下载服务。

Mac软件 更多
灵活计算器
灵活计算器
macOS/iOS/Android

灵活计算器是一款笔记式算数应用,支持实时计算、动态关联和云端同步功能。记录、整理和输出之间的过渡会更自然,适合长期写作、做笔记或持续沉淀个人内容。

赤友清理大师
赤友清理大师
macOS

赤友清理大师是一款为 Mac 设计的智能清理优化工具,可精准扫描垃圾、大文件、重复文件等,释放磁盘空间。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

极度公式
极度公式
Windows/macOS/Linux

极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

WINDOWS 更多
Windows 10
Windows 10
Windows

Windows 10 是一款微软推出的经典操作系统,拥有硬件兼容性与多任务处理能力。它更偏向把系统状态查看和常用调节动作放在一起,适合需要持续观察和微调设备状态的场景。

极度公式
极度公式
Windows/macOS/Linux

极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。

密码键盘
密码键盘
Windows/macOS/iOS/Android

密码键盘是一款兼具安全性与便捷性的高效密码管理器。日常使用里的持续防护和信息管理会更突出,适合把安全控制放进长期使用流程中的场景。