Spring Boot 测试实战：单元测试与集成测试的最佳实践（万字深度解析 Mockito）

本文深入探讨了Spring Boot测试中的单元测试与集成测试最佳实践，重点解析了Mockito框架的应用。文章从测试金字塔模型入手，强调自动化测试在敏捷开发中的重要性。通过对比@Mock与@MockBean、@Spy与@SpyBean的区别，揭示组件测试中的关键选择策略。实战部分展示了Mockito的高级用法，包括打桩、验证和断言技巧。此外，文章还介绍了测试数据初始化的三种模式（Object M

一只当过兵的程序猿

1211人浏览 · 2026-01-24 15:45:00

一只当过兵的程序猿 · 2026-01-24 15:45:00 发布

文章目录

🎯🔥 Spring Boot 测试实战：单元测试与集成测试的最佳实践（万字深度解析 Mockito）

🌟🌍 第一章：引言——测试是高质量代码的“防御之盾”

在现代敏捷开发和 CI/CD（持续集成/持续部署）的浪潮下，软件发布的频率从“月级”进化到了“天级”甚至“小时级”。在这种极致的效率追求下，如何保证系统不崩溃？答案只有一个：自动化测试。

1.1 📈 软件测试的“金字塔”模型

在工业级开发中，我们遵循谷歌提出的“测试金字塔”：

单元测试（Unit Test）：底层最广，速度最快，成本最低。它聚焦于单个方法或组件的逻辑。
集成测试（Integration Test）：中间层，验证多个组件、数据库、中间件之间的交互。
端到端测试（UI/E2E Test）：最顶层，模拟真实用户操作，成本最高，速度最慢。

许多团队的测试现状是“倒金字塔”，即依赖大量的人工点点点或系统级测试，导致发现 Bug 的周期极长。Spring Boot 强大的测试模块（spring-boot-starter-test）正是为了帮助我们将重心下移，构建稳固的底层防线。

1.2 🛡️ 为什么选择 JUnit 5 + Mockito + AssertJ？

Spring Boot 默认集成了这三大神兵：

JUnit 5：新一代测试引擎，提供了强大的生命周期管理。
Mockito：模拟框架的王者，通过“虚假”对象隔离外部依赖。
AssertJ：流式断言库，让断言写起来像读英语句子一样自然。

📊📋 第二章：深度拆解——Mockito 的“模拟艺术”与组件博弈

在 Spring 环境中，我们经常需要在“隔离测试”和“上下文测试”之间切换。这引出了开发者最头疼的一组概念：@Mock vs. @MockBean，@Spy vs. @SpyBean。

2.1 🧬 @Mock 与 @MockBean：身份的本质区别

@Mock (Mockito 原生)：它创建一个纯粹的模拟对象。它不感知 Spring 容器。它适用于不启动 Spring 上下文的纯单元测试。速度极快，是我们的首选。
@MockBean (Spring Boot 提供)：它是 Spring 的“内鬼”。它会创建一个 Mock 对象，并替换掉 Spring ApplicationContext 中原有的那个 Bean。它适用于需要 @SpringBootTest 或 @WebMvcTest 的集成测试场景。

2.2 🔄 @Spy 与 @SpyBean：真实的“影子”

@Spy：它包装一个真实的对象。如果你没对某个方法进行 stub（打桩），它会执行真实的逻辑。就像是一个监控器，既能观察真实行为，也能在必要时干预。
@SpyBean：同样，它是将这个“影子对象”注入到 Spring 容器中。

2.3 ⚠️ 性能陷阱：小心 Context Caching

每一个 @MockBean 都会导致 Spring 尝试创建一个新的 ApplicationContext，除非多个测试类的配置完全一致。如果你滥用 @MockBean，你会发现你的测试跑得越来越慢，因为系统在不断地重启容器。架构师建议：能用纯 @Mock 的地方，绝不用 @MockBean。

💻🚀 代码实战：Mock 与 Spy 的高级用法

/**
 * 业务服务类
 */
@Service
public class OrderService {
    @Autowired private StockClient stockClient;
    @Autowired private PaymentService paymentService;

    public String processOrder(String orderId) {
        if (!stockClient.hasStock(orderId)) {
            return "NO_STOCK";
        }
        return paymentService.pay(orderId);
    }

    public double calculateTax(double price) {
        return price * 0.1;
    }
}

/**
 * 单元测试类
 */
@ExtendWith(MockitoExtension.class) // 启用 Mockito 插件，无需启动 Spring
class OrderServiceTest {

    @Mock
    private StockClient stockClient; // 纯模拟

    @Spy
    private PaymentService paymentService; // 包装真实对象

    @InjectMocks
    private OrderService orderService; // 自动将 mock/spy 注入到此处

    @Test
    void testProcessOrder_Success() {
        // 1. 打桩 (Stubbing)
        when(stockClient.hasStock("ORD-001")).thenReturn(true);
        // paymentService 是 Spy，如果不 stub，它会执行真实 pay 方法
        doReturn("SUCCESS").when(paymentService).pay("ORD-001");

        // 2. 执行
        String result = orderService.processOrder("ORD-001");

        // 3. 断言 (AssertJ)
        assertThat(result).isEqualTo("SUCCESS");

        // 4. 验证调用次数
        verify(stockClient, times(1)).hasStock(anyString());
    }
}

🌍📈 第三章：实战演练——测试数据初始化的“优雅之道”

测试的成败往往不在于逻辑，而在于数据。如果每个测试类都手动 new 十几个对象，代码将变得不可维护。

3.1 🏗️ 模式一：Object Mother (对象母亲)

创建一个专门的 TestDataFactory 类，预定义各种“典型”对象。

优点：集中管理，重用性高。
缺点：对象属性固定，难以处理细微差异。

3.2 🛠️ 模式二：Test Data Builder (构造者)

利用 Lombok 的 @Builder 或手动实现。

优点：链式调用，极其灵活。
示例：User.builder().name("张三").age(18).build();

3.3 🧬 模式三：数据驱动与 Faker

使用 java-faker 库生成随机的姓名、地址、邮箱，增加测试的覆盖面，防止“硬编码测试”导致的逻辑偏差。

3.4 📊 物理隔离：H2 与 Testcontainers

H2 (内存数据库)：速度快，但与生产环境（如 MySQL/PostgreSQL）的语法差异可能导致测试通过但线上报错。
Testcontainers (云原生首选)：通过 Docker 动态启动一个真实数据库镜像。它是目前的工业标准。

💻🚀 代码实战：使用 TestDataBuilder 与 AssertJ 深度断言

public class UserBuilder {
    private User user = new User();

    public static UserBuilder aUser() {
        return new UserBuilder();
    }

    public UserBuilder withVip() {
        user.setVip(true);
        user.setDiscount(0.8);
        return this;
    }

    public User build() {
        return user;
    }
}

// 在测试中使用
@Test
void testVipDiscount() {
    User vipUser = UserBuilder.aUser().withVip().build();
    
    // AssertJ 强大的流式断言
    assertThat(vipUser)
        .extracting(User::getDiscount)
        .isNotNull()
        .isEqualTo(0.8);
}

🔄🎯 第四章：案例研究——Controller 层测试覆盖率从 0 到 90%

Controller 层是系统的门户。测试 Controller 不仅仅是测逻辑，更是在测 HTTP 协议映射、参数校验、异常处理、序列化结果。

4.1 🛡️ @WebMvcTest：轻量级切片测试

不要用 @SpringBootTest 测 Controller，它会启动整个容器（包括数据库连接、RPC），太慢！使用 @WebMvcTest(YourController.class)，它只启动相关的 MVC 组件。

4.2 📊 MockMvc：模拟 HTTP 交互

MockMvc 是 Spring 测试的灵魂。它允许你在不启动服务器的情况下，模拟发送请求并验证返回结果。

4.3 🧪 覆盖率提升的三大法宝

正向路径：参数合法，返回 200 及预期的 JSON。
异常路径：参数缺失或格式错误，验证是否返回 400 及定义的错误信息。
权限路径：如果不带 Token，验证是否返回 401/403。

💻🚀 工业级 Controller 测试案例

@WebMvcTest(OrderController.class)
class OrderControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private OrderService orderService; // 替换 Spring 容器中的服务

    @Test
    @DisplayName("创建订单 - 成功路径")
    void createOrder_shouldReturn201() throws Exception {
        // 1. 准备数据
        OrderDTO request = new OrderDTO("PROD-1", 2);
        when(orderService.create(any())).thenReturn("ORDER-99");

        // 2. 执行 HTTP 请求
        mockMvc.perform(post("/api/orders")
                .contentType(MediaType.APPLICATION_BITSTREAM_VALUE)
                .content("{\"productId\":\"PROD-1\", \"quantity\":2}"))
        // 3. 断言响应
                .andExpect(status().isCreated())
                .andExpect(jsonPath("$.orderId").value("ORDER-99"))
                .andExpect(jsonPath("$.status").value("SUCCESS"));
    }

    @Test
    @DisplayName("创建订单 - 参数校验失败")
    void createOrder_invalidParam_shouldReturn400() throws Exception {
        mockMvc.perform(post("/api/orders")
                .content("{}") // 空 JSON，触发 @Valid 校验
                .contentType(MediaType.APPLICATION_JSON))
                .andExpect(status().isBadRequest());
    }
}