5Building Microservices(第2版)

测试

微服务测试

消费者驱动契约集成测试端到端测试测试金字塔

🎯 AI 时代的学习建议:不要只读理论。理解这一章的设计动机(为什么需要这个概念?)和边界条件(什么情况下会失效?)。当 AI 生成的代码涉及这些概念时,你能判断它是否用对了场景。AI 能帮你总结内容,但无法替代你亲手阅读、思考、建立直觉的过程。

第5章:测试(Testing)

一、导读

1.1 本章学习目标

第5章讲解微服务的测试策略。微服务的分布式特性使测试更加复杂,需要新的测试方法。

1.2 为什么第五章如此重要

测试是微服务质量的保障。但微服务的测试面临独特挑战:多个服务协作、网络通信、数据一致性。

1.3 核心问题引导

微服务测试面临哪些挑战?

消费者驱动契约是什么?

集成测试如何设计?

端到端测试的价值和局限是什么?


二、核心概念详解

5.1 测试金字塔(微服务版)

/  E2E 测试  \        少量
       /  集成测试     \     适量
      /  消费者契约测试  \   适量
     /   单元测试         \  大量

5.2 消费者驱动契约

消费者定义期望:
- 消费者编写契约测试
- 描述对 API 的期望
- 提供者验证契约

工具:Pact

好处:
- 接口变更不会破坏消费者
- 减少集成测试的数量
- 接口文档即测试

5.3 集成测试

java
// 使用 Testcontainers 进行集成测试
@Test
public void shouldPersistOrder() {
    // 启动真实的数据库
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:14");
    
    // 测试真实的数据库交互
    OrderRepository repo = new JdbcOrderRepository(postgres.getJdbcUrl());
    repo.save(order);
    Order found = repo.findById(order.getId());
    assertEquals(order, found);
}

5.4 端到端测试

E2E 测试策略:
- 覆盖核心业务流程
- 使用真实环境或类生产环境
- 关注用户场景而非技术细节
- 数量要少,因为维护成本高

三、实战案例

5.1 消费者驱动契约测试

java
// 消费者测试
@Pact(consumer = "OrderService")
public RequestResponsePact createOrderPact(PactDslWithProvider builder) {
    return builder
        .given("Product 123 exists")
        .uponReceiving("a request to get product 123")
        .path("/products/123")
        .method("GET")
        .willRespondWith()
        .status(200)
        .body(new Product("123", "Widget", 9.99))
        .toPact();
}

// 提供者验证
@Provider("ProductService")
@PactFolder("pacts")
class ProductServiceTest {
    // 验证是否满足消费者的契约
}

四、本章小结

微服务测试需要分层策略。单元测试最多,消费者契约测试验证接口兼容性,集成测试验证组件协作,E2E 测试验证核心流程。


五、思考与练习

微服务测试有哪些独特挑战?

消费者驱动契约如何工作?

集成测试如何管理依赖?

E2E 测试如何保持可靠?

如何平衡测试覆盖度和开发速度?


5/8测试
0%