1. 项目概述：从面试题到实战的跨越

最近在帮团队面试Java后端开发，发现一个挺有意思的现象：很多候选人能把Spring Boot的注解、配置背得滚瓜烂熟，但一涉及到“如何为你的HRM（人力资源管理系统）模块编写可维护的集成测试”这类实战问题时，回答就开始变得含糊。要么是“用 @SpringBootTest 启动整个应用”，要么是“Mock掉数据库层”，再深入问一句“为什么选择这个策略？测试数据如何隔离？事务怎么处理？”很多人就卡壳了。这让我意识到，面试中那些关于Spring Boot测试框架的“八股文”，和实际项目中的高质量测试实践，中间隔着一道不小的鸿沟。

这次，我就结合一个典型的HRM系统场景——员工信息管理模块，来一次深度拆解。我们不只停留在 @SpringBootTest 、 @MockBean 这些注解的表面使用，更要深入到测试策略的选择、测试数据的生命周期管理、以及如何构建一个既快速又可靠的测试套件。你会发现，一个设计良好的测试体系，不仅是代码质量的保障，更是项目迭代速度和团队信心的基石。无论你是正在准备面试，希望跳出纯理论的窠臼，还是已经在项目中负责测试架构，想要优化现有的测试代码，这篇从面试实录出发的实战解析，应该都能给你带来一些新的思路和可以直接“抄作业”的方案。

2. 测试框架核心思想与策略选型

在动手写任何测试代码之前，我们必须先想清楚测试策略。Spring Boot的测试支持非常丰富，但“手里有锤子，看什么都像钉子”是常见误区。不同的测试类型有不同的职责和适用场景，用错了地方，要么测试慢得无法接受，要么根本测不出问题。

2.1 测试金字塔在Spring Boot中的映射

经典的测试金字塔（单元测试 > 集成测试 > 端到端测试）在Spring Boot项目中有了更具体的形态。对于我们的HRM员工模块，可以这样划分：

  • 单元测试（占比70%+） ：目标是验证单个类（如 EmployeeService ）或方法在隔离环境下的行为是否正确。这里的关键是“隔离”。我们使用 Mockito 或 JUnit 5 的 @ExtendWith(MockitoExtension.class) ，将所有依赖（如 EmployeeRepository 、外部邮件服务 EmailService ）都Mock掉。测试只关注被测对象自身的逻辑。例如，测试 EmployeeService.calculateAnnualLeave() 方法，我们Mock一个返回特定入职日期的 EmployeeRepository ，然后断言计算结果是否符合公司规定。这类测试应该最多、运行最快（毫秒级）。
  • 集成测试（占比20%-25%） ：目标是验证多个组件协同工作是否正常。在Spring Boot中，这通常意味着需要启动一部分Spring上下文。例如，测试 EmployeeController 的REST API是否能够正确接收请求、调用 EmployeeService 、并通过 EmployeeRepository 与真实数据库（通常是内存数据库如H2）交互。我们会用到 @SpringBootTest ，但会通过 @AutoConfigureMockMvc 或 @Testcontainers 来限定范围。这类测试比单元测试慢，但能发现组件间集成的问题。
  • 端到端测试（占比<5%） ：模拟真实用户操作，验证整个应用流程。例如，使用 Selenium 或 Playwright 打开浏览器，完成从登录、搜索员工、到编辑信息的完整流程。这类测试最慢、最脆弱，但能发现前端与后端集成、以及环境配置等高层问题。在Spring Boot项目中，这类测试通常独立于后端测试套件。

很多面试者能说出金字塔概念，但在实际项目中，却把大量 @SpringBootTest （它默认会加载整个应用上下文）当作单元测试来写，导致测试启动一次要几十秒，团队逐渐不愿意运行测试。 第一个核心避坑点就是：严格区分测试类型，并为其选择最轻量级的启动方式。

2.2 @SpringBootTest 的深度配置：别动不动就加载全部

@SpringBootTest 是集成测试的入口，但它不是只有一种用法。通过它的参数，我们可以精确控制Spring上下文的加载范围，这是提升测试速度的关键。

// 反面教材：加载全部，慢！
@SpringBootTest
class EmployeeServiceTest {
    // ... 
}

// 正面教材：按需加载，快！
// 场景1：只测试Web层（Controller），不加载数据层和无关的Service
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK) // 使用模拟的Servlet环境
@AutoConfigureMockMvc // 自动配置MockMvc
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) // 不使用嵌入式数据库替换
class EmployeeControllerTest {
    @Autowired
    private MockMvc mockMvc;
    // 测试 /api/employees 等端点
}

// 场景2：测试Service层与Repository层集成，需要真实数据库
@SpringBootTest
@DataJpaTest // 关键！只初始化JPA相关的组件，极大缩小上下文
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY) // 使用嵌入式H2数据库
class EmployeeRepositoryIntegrationTest {
    @Autowired
    private TestEntityManager entityManager; // 用于操作测试数据
    @Autowired
    private EmployeeRepository repository;
    // 测试复杂的JPQL查询或自定义Repository方法
}

实操心得 ：在项目中，我通常会建立一个 AbstractIntegrationTest 基类，根据模块特性预配置好 @SpringBootTest 的参数（如 webEnvironment 、 properties ）。具体的测试类继承它，再通过 @TestConfiguration 注入测试专用的Bean（如一个Mock的第三方客户端）。这样既能保证一致性，又能避免在每个测试类上重复编写冗长的注解。

2.3 测试数据管理：隔离、可重复与性能

集成测试绕不开数据。如何准备测试数据，并在测试结束后清理，是保证测试独立、可重复运行的核心。

  1. @Sql 注解 ：适合数据模式固定、数据量小的场景。可以在测试方法或类上使用 @Sql(scripts = "/data/insert-employees.sql") 来执行SQL脚本初始化数据，并用 @Sql(scripts = "/data/cleanup.sql", executionPhase = Sql.ExecutionPhase.AFTER_TEST_METHOD) 来清理。优点是清晰、直接。缺点是SQL脚本维护成本高，且与Java代码分离。
  2. 使用Repository或 TestEntityManager ：在 @DataJpaTest 中，更推荐使用 TestEntityManager.persist() 或直接调用 Repository.save() 来构建数据。这样数据构建逻辑就在Java代码中，更容易维护和重构。 关键技巧 ：为每个测试方法创建独立的数据集，避免测试间相互影响。可以利用 @BeforeEach 初始化， @AfterEach 清理，或者使用事务回滚。
  3. 事务回滚（默认行为） ： @SpringBootTest 默认会为每个测试方法开启一个事务，并在方法结束后回滚。这意味着你在测试中插入的数据不会真正提交到数据库，完美实现了隔离。 但这里有个大坑 ：如果你在测试中手动获取了数据库连接（比如用 JdbcTemplate ）或者调用了标记为 @Transactional(propagation = Propagation.NEVER) 的方法，回滚可能会失效。务必检查测试数据库在测试后是否有残留数据。
  4. @Testcontainers 用于复杂依赖 ：当你的模块依赖一个真实的外部服务（如Redis、Elasticsearch、或者特定版本的MySQL）时，内存数据库H2可能无法完全模拟其行为。这时可以使用 @Testcontainers 启动一个Docker容器来提供真实的依赖服务。虽然比H2慢，但比Mock更真实，且能保证环境一致性。对于HRM系统，如果使用了复杂的全文检索（Elasticsearch），这个工具就非常有用。

我的经验是 ：对于核心业务逻辑的集成测试，优先使用 @DataJpaTest + TestEntityManager + 事务回滚。对于涉及多个微服务或外部中间件的场景，再考虑 @Testcontainers 。永远要为测试数据库配置一个独立的Schema（如 testdb ），并与开发、生产环境严格隔离。

3. HRM系统员工模块测试实战拆解

理论说再多，不如看代码。我们假设HRM系统的员工模块包含以下核心功能：员工信息增删改查（CRUD）、根据部门/状态筛选、计算年假。我们来一步步构建它的测试体系。

3.1 领域模型与Repository层测试

首先，我们有一个 Employee 实体和对应的 EmployeeRepository （继承 JpaRepository ）。

@Entity
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String employeeNumber;
    @Enumerated(EnumType.STRING)
    private Department department;
    private LocalDate hireDate;
    private Boolean active;
    // getters and setters
}

public interface EmployeeRepository extends JpaRepository<Employee, Long> {
    List<Employee> findByDepartmentAndActiveTrue(Department department);
    Optional<Employee> findByEmployeeNumber(String employeeNumber);
}

对于 EmployeeRepository ，我们重点测试自定义的查询方法。这里使用 @DataJpaTest 是最佳选择。

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)
class EmployeeRepositoryTest {
    @Autowired
    private TestEntityManager entityManager;
    @Autowired
    private EmployeeRepository employeeRepository;

    @BeforeEach
    void setUp() {
        // 准备测试数据
        Employee emp1 = new Employee(null, "张三", "EMP001", Department.ENGINEERING, LocalDate.of(2020, 1, 1), true);
        Employee emp2 = new Employee(null, "李四", "EMP002", Department.ENGINEERING, LocalDate.of(2021, 6, 1), false); // 非活跃
        Employee emp3 = new Employee(null, "王五", "EMP003", Department.HR, LocalDate.of(2019, 3, 15), true);
        entityManager.persist(emp1);
        entityManager.persist(emp2);
        entityManager.persist(emp3);
        entityManager.flush(); // 立即写入，确保后续查询能查到
    }

    @Test
    void findByDepartmentAndActiveTrue_ShouldReturnOnlyActiveEmployeesInGivenDepartment() {
        // When
        List<Employee> result = employeeRepository.findByDepartmentAndActiveTrue(Department.ENGINEERING);
        // Then
        assertThat(result).hasSize(1); // 只有张三
        assertThat(result.get(0).getName()).isEqualTo("张三");
        assertThat(result.get(0).isActive()).isTrue();
    }

    @Test
    void findByEmployeeNumber_WhenExists_ShouldReturnEmployee() {
        Optional<Employee> result = employeeRepository.findByEmployeeNumber("EMP001");
        assertThat(result).isPresent();
        assertThat(result.get().getName()).isEqualTo("张三");
    }

    @Test
    void findByEmployeeNumber_WhenNotExists_ShouldReturnEmpty() {
        Optional<Employee> result = employeeRepository.findByEmployeeNumber("EMP999");
        assertThat(result).isEmpty();
    }
}

注意事项 ： @DataJpaTest 默认会寻找主配置类（ @SpringBootApplication 标注的类）。如果你的项目是多模块的，或者主配置类在别的包，可能需要使用 @DataJpaTest 的 properties 属性或 @Import 来指定配置。

3.2 Service层业务逻辑与Mock策略

EmployeeService 包含核心业务逻辑，如计算年假。它的依赖可能包括 EmployeeRepository 和 LeavePolicyService （一个计算假期政策的复杂服务）。对于单元测试，我们要Mock所有依赖。

@Service
@Transactional
public class EmployeeService {
    private final EmployeeRepository employeeRepository;
    private final LeavePolicyService leavePolicyService;

    public EmployeeService(EmployeeRepository employeeRepository, LeavePolicyService leavePolicyService) {
        this.employeeRepository = employeeRepository;
        this.leavePolicyService = leavePolicyService;
    }

    public int calculateAnnualLeave(Long employeeId) {
        Employee employee = employeeRepository.findById(employeeId)
                .orElseThrow(() -> new EmployeeNotFoundException(employeeId));
        // 假设年假计算依赖于司龄和职级，这里调用一个复杂的策略服务
        return leavePolicyService.calculateDays(employee.getHireDate(), employee.getLevel());
    }
}

对应的单元测试：

@ExtendWith(MockitoExtension.class) // 使用JUnit 5和Mockito
class EmployeeServiceUnitTest {
    @Mock
    private EmployeeRepository employeeRepository;
    @Mock
    private LeavePolicyService leavePolicyService;
    @InjectMocks // 自动将上述Mock注入到被测试对象
    private EmployeeService employeeService;

    @Test
    void calculateAnnualLeave_WhenEmployeeExists_ShouldReturnCalculatedDays() {
        // Given
        Long employeeId = 1L;
        Employee mockEmployee = new Employee(employeeId, "张三", "EMP001", Department.ENGINEERING, LocalDate.of(2020, 1, 1), true);
        mockEmployee.setLevel(Employee.Level.SENIOR);
        when(employeeRepository.findById(employeeId)).thenReturn(Optional.of(mockEmployee));
        when(leavePolicyService.calculateDays(mockEmployee.getHireDate(), mockEmployee.getLevel())).thenReturn(15);

        // When
        int days = employeeService.calculateAnnualLeave(employeeId);

        // Then
        assertThat(days).isEqualTo(15);
        verify(employeeRepository).findById(employeeId); // 验证交互
        verify(leavePolicyService).calculateDays(mockEmployee.getHireDate(), mockEmployee.getLevel());
    }

    @Test
    void calculateAnnualLeave_WhenEmployeeNotExists_ShouldThrowException() {
        Long employeeId = 999L;
        when(employeeRepository.findById(employeeId)).thenReturn(Optional.empty());

        assertThatThrownBy(() -> employeeService.calculateAnnualLeave(employeeId))
                .isInstanceOf(EmployeeNotFoundException.class)
                .hasMessageContaining(String.valueOf(employeeId));
        verify(leavePolicyService, never()).calculateDays(any(), any()); // 确保策略服务未被调用
    }
}

这里的关键点 ：我们使用 @ExtendWith(MockitoExtension.class) 而非 @SpringBootTest ，测试启动速度极快。 @Mock 创建模拟依赖， @InjectMocks 创建被测对象并自动注入Mock。我们不仅断言结果（ assertThat(days).isEqualTo(15) ），还通过 verify 验证了Service与Repository、PolicyService的交互行为是否符合预期，这是单元测试的进阶用法。

3.3 Controller层API测试与 MockMvc

对于REST API，我们使用 @WebMvcTest 。它只加载Web层相关的Bean（Controller, ControllerAdvice, Filter等），不加载Service和Repository，因此速度也很快。我们需要Mock掉Service层。

@WebMvcTest(EmployeeController.class) // 只加载EmployeeController
class EmployeeControllerTest {
    @Autowired
    private MockMvc mockMvc;
    @MockBean // 注意这里是@MockBean，不是@Mock。用于在Spring上下文中替换掉真实的Bean。
    private EmployeeService employeeService;

    @Test
    void getEmployee_WhenExists_ShouldReturnEmployeeAnd200() throws Exception {
        EmployeeDto mockDto = new EmployeeDto(1L, "张三", "EMP001", "ENGINEERING");
        when(employeeService.getEmployeeById(1L)).thenReturn(mockDto);

        mockMvc.perform(get("/api/employees/1")
                        .accept(MediaType.APPLICATION_JSON))
                .andExpect(status().isOk())
                .andExpect(jsonPath("$.name").value("张三"))
                .andExpect(jsonPath("$.employeeNumber").value("EMP001"));
    }

    @Test
    void createEmployee_WithValidInput_ShouldReturn201AndLocationHeader() throws Exception {
        EmployeeCreateRequest request = new EmployeeCreateRequest("李四", "HR");
        EmployeeDto createdDto = new EmployeeDto(2L, "李四", "AUTO_GEN", "HR");
        when(employeeService.createEmployee(any(EmployeeCreateRequest.class))).thenReturn(createdDto);

        mockMvc.perform(post("/api/employees")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content("{\"name\":\"李四\",\"department\":\"HR\"}"))
                .andExpect(status().isCreated())
                .andExpect(header().string("Location", "/api/employees/2"));
    }

    @Test
    void createEmployee_WithInvalidInput_ShouldReturn400() throws Exception {
        // 测试验证失败场景
        mockMvc.perform(post("/api/employees")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content("{\"name\":\"\",\"department\":\"INVALID_DEPT\"}")) // 空名字，无效部门
                .andExpect(status().isBadRequest())
                .andExpect(jsonPath("$.errors").isArray());
        verify(employeeService, never()).createEmployee(any()); // 确保Service未被调用
    }
}

使用 @MockBean 的注意事项 ：它会将Spring应用上下文中的对应Bean替换为Mockito mock。这意味着，如果在同一个测试类中还有 @Autowired 这个Bean的地方，注入的也会是这个Mock。要确保Mock的行为在多个测试方法间是隔离的，通常需要在 @BeforeEach 中重置Mock（ Mockito.reset(...) ）或为每个测试方法单独配置 when 。

3.4 切片测试（ @JsonTest , @JdbcTest 等）的应用

Spring Boot提供了一系列“切片测试”注解，用于针对性测试某一技术层面。

  • @JsonTest ：专注于测试JSON序列化/反序列化。非常适合测试你的DTO或实体与Jackson的配合，比如自定义序列化器、 @JsonFormat 日期格式等。 
    @JsonTest
class EmployeeDtoJsonTest {
    @Autowired
    private JacksonTester<EmployeeDto> json;
    @Test
    void serialize_ShouldIncludeCorrectFields() throws Exception {
        EmployeeDto dto = new EmployeeDto(1L, "张三", "EMP001", "ENGINEERING");
        assertThat(json.write(dto)).isEqualToJson("expected-employee.json");
        // 或者断言特定字段
        assertThat(json.write(dto)).hasJsonPathStringValue("$.name");
        assertThat(json.write(dto)).doesNotHaveJsonPath("$.password"); // 确保敏感字段不泄露
    }
}
  • @JdbcTest ：如果你使用的是JdbcTemplate而非JPA，这个注解就比 @DataJpaTest 更合适。

选择策略 ：当你的测试焦点非常明确时（比如只测JSON、只测JDBC），使用切片测试能获得最快的启动速度。如果测试需要多个技术组件（如Web层+JSON序列化），则 @WebMvcTest 或 @SpringBootTest （限定范围）更合适。

4. 高级场景与测试基础设施构建

当项目变得复杂，简单的 @MockBean 和内存数据库可能不够用。我们需要更强大的工具和模式。

4.1 测试配置外部化与Profile管理

不要把测试配置（如数据库URL、第三方服务的Mock端点）硬编码在 application.properties 里。使用 application-test.properties 文件，并通过 @ActiveProfiles("test") 激活。

# application-test.properties
spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;MODE=MYSQL
spring.datasource.driver-class-name=org.h2.Driver
# 关闭一些生产环境才需要的功能，加快测试速度
spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.show-sql=true
# 指向一个本地WireMock实例来Mock外部HR薪酬服务
hr.payroll.service.base-url=http://localhost:9090/mock-payroll

在测试类上使用 @ActiveProfiles("test") ，Spring Boot就会加载这个配置文件。对于需要Mock的外部服务，我强烈推荐使用 WireMock 。你可以通过 @AutoConfigureWireMock 注解，在测试中动态地桩（stub）外部HTTP API的响应。

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureWireMock(port = 9090) // 在9090端口启动一个WireMock服务器
@ActiveProfiles("test")
class EmployeeServiceWithExternalCallTest {
    @Test
    void syncEmployeeToPayroll_WhenExternalCallSucceeds_ShouldReturnSuccess() {
        // Given: 桩住外部薪酬服务的API
        stubFor(post(urlEqualTo("/mock-payroll/employees"))
                .willReturn(aResponse()
                        .withStatus(201)
                        .withHeader("Content-Type", "application/json")
                        .withBody("{\"externalId\": \"EXT123\"}")));

        // When & Then: 调用你的业务方法，它会请求http://localhost:9090/mock-payroll/employees
        // 使用MockMvc或直接调用Service进行测试
        // ...
    }
}

4.2 自定义测试注解与模板方法

如果你发现多个测试类都有相同的注解组合（如 @SpringBootTest + @ActiveProfiles("integration") + @Testcontainers ），可以创建一个自定义的元注解。

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@SpringBootTest
@ActiveProfiles("integration")
@Testcontainers
@AutoConfigureMockMvc
public @interface IntegrationTest {
}

然后你的集成测试类就可以简化为：

@IntegrationTest
class EmployeeServiceIntegrationTest {
    // ... 测试内容
}

这大大减少了样板代码，并确保了配置的一致性。对于需要启动真实数据库容器的测试，可以在基类里用 @Container 定义静态的PostgreSQL容器，所有继承该基类的测试都会共享这个容器（在类级别只启动一次），提升测试效率。

4.3 测试覆盖率与持续集成集成

写测试不是目的，保证代码质量才是。使用 Jacoco 或 Clover 等工具来生成测试覆盖率报告。在Maven或Gradle中配置后，每次构建都能看到行覆盖率、分支覆盖率等指标。

重要的不是盲目追求高覆盖率（比如95%以上） ，而是关注核心业务逻辑、复杂条件分支、异常处理路径是否被覆盖到。在CI/CD流水线中，可以设置覆盖率门槛（如核心模块行覆盖率不低于80%），如果未达到则构建失败。

此外，将测试分层执行能优化CI时间：

  1. 快速反馈层 ：只运行所有单元测试（ *Test 或 *UnitTest ）。这应该在每次提交后立即触发，几分钟内完成。
  2. 集成验证层 ：运行集成测试（ *IntegrationTest ）。这可以在合并请求（Pull Request）时触发，耗时稍长但可接受。
  3. 全面验收层 ：运行包括端到端测试在内的所有测试。这通常在每日夜间构建或发布前进行。

5. 常见问题排查与性能优化实录

在实际项目中，测试总会遇到各种奇怪的问题。这里记录几个我踩过的坑和解决方案。

5.1 事务回滚失效问题

问题现象 ：测试方法结束后，数据库里留下了测试数据，污染了后续测试。 排查思路 ：

  1. 检查测试类或方法上是否有 @Transactional 注解。 @SpringBootTest 默认是有的，但如果你手动加了一个并设置了 propagation = Propagation.REQUIRES_NEW ，可能会创建新事务。
  2. 检查是否在测试中使用了 JdbcTemplate 或原生JDBC直接执行了 COMMIT 。
  3. 检查是否调用了被 @Transactional(propagation = Propagation.NEVER) 标注的方法，这会导致事务上下文挂起。
  4. 某些数据库操作（如DDL语句）在某些配置下会自动提交。

解决方案 ：最简单的办法是在测试方法上添加 @Rollback 注解（即使默认是true，显式声明也更清晰）。如果问题复杂，可以考虑在 @AfterEach 方法中手动清理数据，或者使用 @DirtiesContext 注解（但这会重置整个Spring上下文，非常慢，应作为最后手段）。

5.2 @MockBean 导致的上下文污染

问题现象 ：在测试类A中Mock了 EmailService ，导致测试类B（也依赖 EmailService ）运行时，注入的也是被A Mock过的Bean，从而行为异常。 根本原因 ：Spring Test默认会缓存应用上下文以加速测试。如果测试类A和B使用相同的上下文配置，那么A中通过 @MockBean 替换的Bean，在B的上下文中依然是被替换后的Mock实例。 解决方案 ：

  1. 隔离配置 ：确保A和B使用不同的测试配置（如不同的 @TestConfiguration ），迫使Spring创建不同的上下文。
  2. 使用 @DirtiesContext ：在修改了Bean定义的测试类上标注 @DirtiesContext ，告诉Spring这个测试弄脏了上下文，后续测试需要重建。 慎用 ，会显著降低测试速度。
  3. 设计上的解耦 ：反思Mock的Bean是否真的是一个良好的、可替换的接口。有时过度Mock是设计有问题的信号。
  4. 在 @AfterEach 中重置Mock ：对于同一个测试类内的多个测试方法，确保在 @BeforeEach 或 @AfterEach 中调用 Mockito.reset(mockedBean) 来清除上一个测试方法的桩行为。

5.3 测试启动速度缓慢

问题现象 ：本地运行一个简单的测试要等十几秒甚至更久，开发体验极差。 优化手段 ：

  1. 首要任务：减少 @SpringBootTest 的使用 。能用 @WebMvcTest 、 @DataJpaTest 、 @JsonTest 等切片测试的，绝不用全量测试。
  2. 使用 @MockBean 替代真实的重量级Bean ：比如，你的应用里有一个初始化很慢的 CacheManager 或 DataSource ，在不需要测试它们具体功能的测试中，果断Mock掉。
  3. 配置上下文缓存 ：Spring Boot Test本身会缓存上下文。确保你的测试类合理地分组（通过相同的配置），让缓存命中率更高。避免在每个测试类上都使用 @DirtiesContext 。
  4. 使用内存数据库H2，并优化其配置 ： spring.datasource.url 中可以加入 ;DB_CLOSE_DELAY=-1 （保持连接）和 MODE=MySQL （兼容模式）来提升性能。
  5. 检查依赖 ：是否在测试范围内引入了不必要的、庞大的依赖（如整个Spring Cloud套件）？使用 @SpringBootTest 的 classes 属性来显式指定需要加载的配置类，而不是加载所有。

5.4 集成测试中的随机端口与动态配置

当测试需要启动一个真实的服务器实例（ WebEnvironment.RANDOM_PORT 或 DEFINED_PORT ）时，如何获取服务器实际运行的端口和地址？

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class RandomPortExampleTest {
    @LocalServerPort // 注入随机分配的端口
    private int port;
    @Autowired
    private TestRestTemplate restTemplate; // 或者使用RestTemplateBuilder

    @Test
    void testEndpoint() {
        String url = "http://localhost:" + port + "/api/employees";
        ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
        assertThat(response.getStatusCode()).isEqualTo(HttpStatus.OK);
    }
}

TestRestTemplate 是 RestTemplate 的测试友好版本，自动预配置了根路径，非常适合集成测试。对于更复杂的请求构造和响应断言，可以结合 RestAssured ，它能提供更流畅的DSL语法。

构建一个健壮、高效、可维护的Spring Boot测试套件，是一个需要持续投入和优化的过程。它没有银弹，但遵循“测试金字塔”原则，合理运用Spring Boot提供的各种测试切片工具，并建立清晰的测试数据管理和CI策略，能极大地提升项目的长期健康度。从面试的角度看，能清晰阐述这些策略背后的“为什么”的候选人，通常在实际项目中也能写出更高质量的测试代码。

# 集成测试 # 单元测试
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

接入 Hermes 后我砍掉了 30% 的 AI 调用：小团队如何避免过度设计？

avatar AI编程社区
cover

Claude Code真能提效吗？先看流程里最慢的那一步

avatar AI编程社区
cover

撕开AI编程的遮羞布：我在CRM项目中踩过的那些坑

avatar AI编程社区