本文旨在探讨如何针对执行软删除操作的void方法进行单元测试和集成测试。我们将重点分析在使用Mockito模拟依赖时，如何验证对void方法的调用，以及当需要覆盖实际的仓储层（Repository）实现逻辑时，应如何构建测试。通过具体示例，阐明模拟对象与真实代码执行的区别，并提供确保测试覆盖率的策略。
在现代应用程序开发中，软删除（Soft Delete）是一种常见的逻辑删除策略，它通过更新记录的状态（例如，设置deleted字段为true）而非物理删除数据。当涉及到测试包含这类操作的void方法时，开发者常会遇到如何验证其行为以及确保代码覆盖率的问题。
1. 问题背景与挑战分析
考虑以下用户服务（UserService）中的deleteUser方法，它负责根据用户ID执行软删除：
public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public void deleteUser(String id) { var userEntity = userRepository.findById(Integer.valueOf(id)) .orElseThrow(() -> new UserNotFoundException("Id not found")); // 业务规则：如果用户最后访问日期为空，则禁止删除 if (userEntity.getLastAccessDate() == null) { throw new ProhibitedAccessException("Policy has been violated"); } // 执行软删除 userRepository.delete(userEntity); }}
对应的仓储层（UserRepository）中的delete方法使用@Modifying和@Query注解来实现软删除：
public interface UserRepository extends JpaRepository { @Modifying @Query("update UserEntity u set deleted = true where u = :userEntity") void delete(UserEntity userEntity);}
在编写单元测试时，我们通常会模拟UserRepository以隔离UserService的逻辑。一个初步的测试可能如下：
@ExtendWith(MockitoExtension.class)class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; @Test void deleteUserTest_ProhibitedAccess() { final int id = 1; UserEntity userEntity = new UserEntity(); // 默认lastAccessDate为null var idString = String.valueOf(id); when(userRepository.findById(id)).thenReturn(Optional.of(userEntity)); // 预期抛出ProhibitedAccessException，因为lastAccessDate为null assertThrows(ProhibitedAccessException.class, () -> userService.deleteUser(idString)); // 验证findById被调用，但delete方法不会被调用到 verify(userRepository).findById(id); verify(userRepository, never()).delete(any(UserEntity.class)); }}
上述测试能够验证当userEntity.getLastAccessDate()为null时，ProhibitedAccessException被正确抛出。然而，它并不会覆盖userRepository.delete(userEntity)这行代码，因为该行在异常抛出之前无法被执行到。
核心挑战在于：
验证void方法调用：如何确认被模拟对象的void方法在特定条件下被调用了？覆盖实际仓储逻辑：当服务层依赖于仓储层时，如何测试仓储层本身的软删除实现是否正确？模拟对象无法执行真实代码。
2. 验证模拟对象的void方法调用
要验证userRepository.delete(userEntity)是否被调用，我们首先需要调整测试场景，确保业务逻辑允许该方法被执行。这意味着userEntity.getLastAccessDate()不能为null。
我们可以通过Mockito.verify()方法来验证模拟对象上的void方法是否被调用以及调用次数和参数。
示例代码：验证delete方法被调用
import org.junit.jupiter.api.Test;import org.junit.jupiter.api.extension.ExtendWith;import org.mockito.InjectMocks;import org.mockito.Mock;import org.mockito.junit.jupiter.MockitoExtension;import java.time.LocalDateTime;import java.util.Optional;import static org.mockito.Mockito.*;import static org.junit.jupiter.api.Assertions.*;@ExtendWith(MockitoExtension.class)class UserServiceTest { @Mock private UserRepository userRepository; @InjectMocks private UserService userService; // 假设 UserEntity 和相关异常类已定义 // ... (UserEntity, UserNotFoundException, ProhibitedAccessException 定义略) @Test void deleteUserTest_Success() { final int id = 1; UserEntity userEntity = new UserEntity(); userEntity.setId(id); userEntity.setLastAccessDate(LocalDateTime.now()); // 设置非null的lastAccessDate var idString = String.valueOf(id); // 模拟findById返回一个合法的UserEntity when(userRepository.findById(id)).thenReturn(Optional.of(userEntity)); // 执行待测试的方法 userService.deleteUser(idString); // 验证findById方法被调用了一次，参数为id verify(userRepository, times(1)).findById(id); // 验证delete方法被调用了一次，参数为userEntity // 这是覆盖 userRepository.delete(userEntity) 的关键 verify(userRepository, times(1)).delete(userEntity); // 确保没有其他交互（可选） verifyNoMoreInteractions(userRepository); } @Test void deleteUserTest_UserNotFound() { final int id = 2; var idString = String.valueOf(id); when(userRepository.findById(id)).thenReturn(Optional.empty()); assertThrows(UserNotFoundException.class, () -> userService.deleteUser(idString)); verify(userRepository, times(1)).findById(id); verify(userRepository, never()).delete(any(UserEntity.class)); }}
在deleteUserTest_Success测试中，我们通过设置userEntity.setLastAccessDate(LocalDateTime.now())来满足业务规则，使得userRepository.delete(userEntity)这行代码能够被执行到。然后，使用verify(userRepository, times(1)).delete(userEntity)来断言delete方法在模拟对象上被调用了一次，并且传入的参数是预期的userEntity。这解决了验证void方法调用的问题，并确保了userService中调用userRepository.delete这行代码的单元测试覆盖。
3. 测试仓储层（Repository）的实际实现
Mockito.verify()只能验证模拟对象的行为，它并不会执行UserRepository中@Query注解定义的SQL更新操作。如果我们需要测试@Modifying和@Query注解的软删除逻辑是否正确地更新了数据库中的deleted字段，我们就需要编写集成测试（或仓储层切片测试）。
集成测试通常会使用真实的数据库（可以是内存数据库如H2，也可以是测试容器中的实际数据库），并加载Spring Data JPA上下文。
示例代码：仓储层集成测试
import org.junit.jupiter.api.Test;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;import org.springframework.test.context.ActiveProfiles;import java.time.LocalDateTime;import static org.junit.jupiter.api.Assertions.*;@DataJpaTest // 用于测试JPA组件，如Repository@ActiveProfiles("test") // 激活测试配置文件，可能指向H2内存数据库class UserRepositoryIntegrationTest { @Autowired private UserRepository userRepository; @Autowired private TestEntityManager entityManager; // 用于直接操作数据库，如插入测试数据 @Test void softDeleteUserShouldSetDeletedFlagToTrue() { // 准备测试数据 UserEntity user = new UserEntity(); user.setName("Test User"); user.setLastAccessDate(LocalDateTime.now()); user.setDeleted(false); // 初始状态为未删除 entityManager.persistAndFlush(user); // 插入并立即同步到数据库 Integer userId = user.getId(); assertNotNull(userId); assertFalse(userRepository.findById(userId).get().isDeleted()); // 确认初始状态 // 执行软删除操作 userRepository.delete(user); // 调用Repository的delete方法 // 刷新EntityManager以确保所有挂起的更改都已同步到数据库 entityManager.flush(); // 清除EntityManager缓存，以确保从数据库重新加载最新的数据 entityManager.clear(); // 验证软删除是否成功 Optional deletedUserOptional = userRepository.findById(userId); assertTrue(deletedUserOptional.isPresent()); assertTrue(deletedUserOptional.get().isDeleted()); // 断言deleted字段变为true }}
在这个集成测试中：
@DataJpaTest注解加载了Spring Data JPA相关的上下文，使得UserRepository可以与真实的（或模拟的）数据库进行交互。我们首先使用TestEntityManager插入一个UserEntity，并确保其deleted字段初始为false。然后，我们直接调用userRepository.delete(user)方法，这会执行@Query中定义的SQL更新语句。通过entityManager.flush()和entityManager.clear()确保数据库状态与当前测试环境同步，并强制重新从数据库加载数据。最后，我们再次查询该用户，并断言其deleted字段已变为true，从而验证了软删除逻辑的正确性。
4. 注意事项与总结
单元测试 vs. 集成测试：单元测试（UserServiceTest）：侧重于隔离测试单个组件（如UserService）的业务逻辑。通过模拟依赖（UserRepository），可以快速验证组件内部的逻辑流、条件分支和方法调用。Mockito.verify()是验证void方法调用的核心工具。集成测试（UserRepositoryIntegrationTest）：侧重于测试多个组件（如UserService与UserRepository，或UserRepository与数据库）之间的协作。当涉及到Spring Data JPA的@Query、@Modifying等注解的实际数据库交互时，集成测试是不可或缺的。测试场景设计：确保你的测试用例能够覆盖所有可能的代码路径和业务规则。例如，在UserService中，你需要分别测试用户不存在、权限不足（lastAccessDate为null）和成功删除三种情况。模拟对象的行为设置：在使用when()定义模拟对象的行为时，要仔细考虑返回什么值才能触发你想要测试的特定代码路径。测试数据管理：在集成测试中，确保每次测试都有一个干净、可预测的数据库状态。@DataJpaTest通常会回滚事务，但手动插入和清理数据也是常见做法。
通过结合单元测试（验证服务层与模拟仓储层的交互）和集成测试（验证仓储层与真实数据库的交互），我们可以全面、有效地测试包含软删除逻辑的void方法，确保应用程序的健壮性和正确性。
以上就是如何有效测试软删除（Soft-Delete）的Void方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/41621.html
微信扫一扫 
支付宝扫一扫 
