spring-boot-testing

Spring Boot 测试

本技能为测试 Spring Boot 4 应用提供专家指南，涵盖现代模式与最佳实践。

核心原则

1. 测试金字塔：单元（快速）> 切片（聚焦）> 集成（完整）
2. 选对工具：使用能给你信心的最窄切片
3. AssertJ 风格：用流畅、可读的断言取代冗长的匹配器
4. 现代 API：优先使用 MockMvcTester 和 RestTestClient，而非旧式替代方案

选择哪个测试切片？

场景	注解	参考
Controller + HTTP 语义	@WebMvcTest	references/webmvctest.md
Repository + JPA 查询	@DataJpaTest	references/datajpatest.md
REST 客户端 + 外部 API	@RestClientTest	references/restclienttest.md
JSON（反）序列化	@JsonTest	references/test-slices-overview.md
完整应用	@SpringBootTest	references/test-slices-overview.md

测试切片参考

• references/test-slices-overview.md - 决策矩阵与对比
• references/webmvctest.md - 使用 MockMvc 测试 Web 层
• references/datajpatest.md - 使用 Testcontainers 测试数据层
• references/restclienttest.md - REST 客户端测试

测试工具参考

• references/mockmvc-tester.md - AssertJ 风格 MockMvc（3.2+）
• references/mockmvc-classic.md - 传统 MockMvc（3.2 之前）
• references/resttestclient.md - Spring Boot 4+ REST 客户端
• references/mockitobean.md - Mock 依赖

断言库

• references/assertj-basics.md - 标量、字符串、布尔值、日期
• references/assertj-collections.md - List、Set、Map、数组

Testcontainers

• references/testcontainers-jdbc.md - PostgreSQL、MySQL 等

测试数据生成

• references/instancio.md - 生成复杂测试对象（3 个以上属性）

性能与迁移

• references/context-caching.md - 加速测试套件
• references/sb4-migration.md - Spring Boot 4.0 变更

快速决策树

Testing a controller endpoint?
  Yes → @WebMvcTest with MockMvcTester

Testing repository queries?
  Yes → @DataJpaTest with Testcontainers (real DB)

Testing business logic in service?
  Yes → Plain JUnit + Mockito (no Spring context)

Testing external API client?
  Yes → @RestClientTest with MockRestServiceServer

Testing JSON mapping?
  Yes → @JsonTest

Need full integration test?
  Yes → @SpringBootTest with minimal context config

Spring Boot 4 亮点

• RestTestClient：TestRestTemplate 的现代替代方案
• @MockitoBean：取代 @MockBean（已弃用）
• MockMvcTester：用于 Web 测试的 AssertJ 风格断言
• 模块化 starter：针对特定技术的测试 starter
• 上下文暂停：自动暂停已缓存的上下文（Spring Framework 7）

测试最佳实践

代码复杂度评估

当一个方法或类过于复杂、无法有效测试时：

1. 分析复杂度 - 如果覆盖单个方法需要 5-7 个以上测试用例，它很可能过于复杂
2. 建议重构 - 建议将代码拆分为更小、更专注的函数
3. 用户决定 - 如果用户同意重构，帮助识别抽取点
4. 必要时继续 - 如果用户决定继续使用复杂代码，尽管困难也要实现测试

重构建议示例：

// Before: Complex method hard to test
public Order processOrder(OrderRequest request) {
  // Validation, discount calculation, payment, inventory, notification...
  // 50+ lines of mixed concerns
}

// After: Refactored into testable units
public Order processOrder(OrderRequest request) {
  validateOrder(request);
  var order = createOrder(request);
  applyDiscount(order);
  processPayment(order);
  updateInventory(order);
  sendNotification(order);
  return order;
}

避免代码冗余

为常用对象和 mock 设置创建辅助方法，以提升可读性和可维护性。

使用 @DisplayName 组织测试

使用描述性的显示名称来阐明测试意图：

@Test
@DisplayName("Should calculate discount for VIP customer")
void shouldCalculateDiscountForVip() { }

@Test
@DisplayName("Should reject order when customer has insufficient credit")
void shouldRejectOrderForInsufficientCredit() { }

测试覆盖顺序

始终按以下顺序组织测试：

1. 主要场景 - 正常路径，最常见的使用场景
2. 其他路径 - 其他有效场景，边界情况
3. 异常/错误 - 无效输入，错误条件，失败模式

测试生产场景

编写测试时要考虑真实的生产场景。这能让测试更贴近实际，并有助于理解代码在实际生产情况下的行为。

测试覆盖目标

以 80% 代码覆盖率为目标，这是质量与投入之间的实用平衡。更高的覆盖率是有益的，但并非唯一目标。

使用 Jacoco maven 插件进行覆盖率报告和跟踪。

覆盖率规则：

• 至少 80% 覆盖率
• 关注有意义的断言，而不仅仅是执行

优先处理的内容：

1. 业务关键路径（支付处理、订单校验）
2. 复杂算法（定价、折扣计算）
3. 错误处理（异常、边界情况）
4. 集成点（外部 API、数据库）

依赖项（Spring Boot 4）

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
</dependency>


<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webmvc-test</artifactId>
  <scope>test</scope>
</dependency>


<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-testcontainers</artifactId>
  <scope>test</scope>
</dependency>