如何有效测试软删除（Soft-Delete）的Void方法

在现代应用程序开发中，软删除（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)这行代码，因为该行在异常抛出之前无法被执行到。

核心挑战在于：

1. 验证void方法调用：如何确认被模拟对象的void方法在特定条件下被调用了？
2. 覆盖实际仓储逻辑：当服务层依赖于仓储层时，如何测试仓储层本身的软删除实现是否正确？模拟对象无法执行真实代码。

2. 验证模拟对象的void方法调用

要验证userRepository.delete(userEntity)是否被调用，我们首先需要调整测试场景，确保业务逻辑允许该方法被执行。这意味着userEntity.getLastAccessDate()不能为null。

我们可以通过Mockito.verify()方法来验证模拟对象上的void方法是否被调用以及调用次数和参数。

EduPro

EduPro - 留学行业的AI工具箱

下载

示例代码：验证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方法，确保应用程序的健壮性和正确性。