集成测试中的事务隔离挑战
在spring boot集成测试中，我们经常使用@transactional注解来简化测试环境下的数据操作。这个注解通常意味着测试方法将在一个事务中运行，并在测试结束时自动回滚所有数据库操作，以保持数据库状态的清洁。然而，当测试流程中涉及到mockmvc模拟的http请求时，这种默认的事务行为可能会导致意想不到的数据可见性问题。
考虑以下场景：在一个集成测试中，我们首先修改了一个用户实体的唯一名称，并将其保存到数据库中。紧接着，我们使用MockMvc模拟了一个HTTP请求，该请求的头部包含了用户修改前的旧唯一名称。这个请求随后被一个自定义安全过滤器拦截，过滤器会尝试根据请求头中的旧唯一名称从数据库中查找用户。我们期望此时查找不到用户（因为名称已更改），从而触发异常或特定的业务逻辑。然而，实际观察到的现象是，尽管我们查询的是旧名称，系统却找到了该用户，并且其唯一名称字段显示的是新名称。这种现象令人困惑，通常指向事务隔离或缓存问题。
问题剖析：MockMvc与未提交事务的冲突
造成上述现象的核心原因在于事务隔离。
@Transactional测试方法的默认行为： 当一个测试方法被@Transactional注解标记时，Spring会为该方法创建一个事务。在这个事务中，所有对数据库的修改（例如userRepository.saveAndFlush(user)）都会被刷新到当前的持久化上下文（通常是Hibernate的Session），甚至可能写入数据库的日志，但这些修改并未被提交到数据库。默认情况下，Spring测试会在方法执行完毕后回滚此事务，这意味着这些修改对其他事务是不可见的。
MockMvc请求的事务上下文： MockMvc模拟的HTTP请求通常会在一个独立的线程和事务上下文中执行。当请求进入应用程序（例如，通过自定义安全过滤器），应用程序的代码会启动自己的事务（如果配置了事务管理器）。由于主测试方法的事务尚未提交，MockMvc请求所处的这个新事务将无法看到主测试方法中那些未提交的修改。它会查询数据库的已提交状态。
-
数据可见性冲突： 在上述场景中，当主测试方法执行user.setUniqueName("newUniqueName"); userRepository.saveAndFlush(user);时，User实体在当前事务的持久化上下文中已经被更新为newUniqueName。但由于事务未提交，数据库中该用户的uniqueName字段实际上仍为oldUniqueName。当MockMvc请求到达安全过滤器，并调用userRepository.findUserByUniqueName(oldUniqueName)时：
- 如果过滤器运行在一个独立的事务中，它会查询数据库的已提交状态。此时，数据库中仍然存在一个uniqueName为oldUniqueName的用户。
- 至于为何问题描述中会观察到“uniqueName field has the value 'newUniqueName'”，这可能是由于特定的ORM框架（如Hibernate）的会话缓存机制导致的。如果同一个实体实例在当前会话中被加载并修改，即使查询条件是旧值，也可能返回会话中已知的最新状态。然而，根本问题在于MockMvc请求所依赖的数据库状态与测试方法所操作的数据库状态不一致。
简而言之，问题在于MockMvc模拟的请求没有看到测试方法中未提交的数据变更，因为它操作的是数据库的已提交状态。
解决方案：使用TransactionTemplate显式提交
解决此问题的关键在于确保在MockMvc请求执行之前，所有必要的数据修改都已提交到数据库。我们可以通过移除测试方法上的@Transactional注解，并使用Spring的TransactionTemplate来显式管理数据修改部分的事务。
TransactionTemplate允许我们在代码块中声明式地执行事务操作，并在代码块结束时提交或回滚事务，从而提供更细粒度的事务控制。
实现步骤：
- 移除测试方法上的@Transactional注解。 这样测试方法本身将不再被一个默认回滚的事务包裹。
- 注入TransactionTemplate。
- 将需要提交的数据库操作封装在TransactionTemplate.executeWithoutResult()方法中。 这将确保这些操作在一个独立的、可提交的事务中执行。
示例代码：
首先，确保你的测试类能够注入TransactionTemplate：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.AutoConfigureMockMvc;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.transaction.support.TransactionTemplate;
import org.springframework.http.HttpHeaders;
import org.junit.jupiter.api.Test;
import static org.assertj.core.api.Assertions.assertThat;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
@SpringBootTest
@AutoConfigureMockMvc
// 移除 @Transactional 注解
public class UserIntegrationTest {
@Autowired
private UserRepository userRepository;
@Autowired
private MockMvc mockMvc;
@Autowired
private TransactionTemplate transactionTemplate; // 注入 TransactionTemplate
@Test
void testUserUpdateAndSecurityFilter() throws Exception {
// 1. 初始数据准备：确保数据库中存在一个名为 "oldUniqueName" 的用户
// 实际应用中，这部分可能通过 @BeforeEach 或测试数据加载器完成
User initialUser = new User("someId", "oldUniqueName");
userRepository.save(initialUser); // 确保初始用户已提交
// 使用 TransactionTemplate 封装数据更新操作，并确保其提交
transactionTemplate.executeWithoutResult(status -> {
// 在独立的事务中查找并更新用户
User user = userRepository.findUserByUniqueName("oldUniqueName")
.orElseThrow(() -> new RuntimeException("User not found for update"));
assertThat(user).isNotNull();
user.setUniqueName("newUniqueName");
userRepository.saveAndFlush(user); // 刷新并标记为待提交
// transactionTemplate.executeWithoutResult 块结束时，事务会自动提交
});
// 此时，数据库中名为 "oldUniqueName" 的用户已不存在，已被更新为 "newUniqueName"
// 2. 模拟 MockMvc 请求，使用旧的 uniqueName
HttpHeaders headers = new HttpHeaders();
headers.add("UniqueName", "oldUniqueName"); // 添加旧的 uniqueName 到请求头
String endpointUrl = "/api/secure-endpoint"; // 假设的受保护接口
mockMvc.perform(get(endpointUrl).headers(headers)) 
