eBay 和 Lastminute 采用契约测试来驱动架构演进

lastminute.com采用契约测试来降低系统级集成测试所带来的复杂性，并改进反馈周期和开发过程。eBay 也采用契约测试来帮助其内部进行API演化，并为客户端团队提供支持。

在分布式系统（如微服务架构）中，应用程序服务使用 RPC（远程过程调用）风格的请求或异步消息进行交互。测试这类系统的常用方法是使用系统测试（端到端集成测试），这通常需要将整个系统部署在测试环境中。

lastminute.com 的软件工程师Ivan Dell'Oro指出集成/系统测试所带来的挑战：

在过去，我们通过集成测试来验证两个微服务之间的消息交换，由于多种原因会导致测试失败。为避免阻碍开发过程，我们选择忽略这些测试。结果是它们被忽视了好几个月，当一边的系统发生变化，两边的 CI 管道却都是绿色的：通常，当生产环境中出现了故障，应该是契约出现了错误。

eBay 团队也表示：

对于 eBay 的通知平台团队来说，我们面临的另一个挑战是，我们的 API 被许多领域团队调用。在演进服务 API 的同时保持与所有消费者端的兼容性是我们的一个基本原则。

这两个团队都一直在寻找能够让测试变得不那么脆弱和更快速的方法，目标是改善开发人员/测试人员的体验，缩短反馈周期，加快价值交付的速度，同时支持内部契约的演进，例如 API 规范和消息 schema。

最后，经过一些研究和实验，他们采用契约测试作为验证服务间交互正确性的主要方法。lastminute.com 发现，这给他们的微服务架构和交付过程带来了积极的影响，与标准的系统级测试相比，测试执行时间大大缩短了。eBay 使用契约测试来验证其平台中的集成点，支持通过写作来确保内部 API 可以在不出现不兼容问题的情况下演进。

lastminute.com 已经使用Pact（一个客户端驱动的契约测试工具）对微服务之间的 RPC 交互进行了契约测试，并在随后将其扩展到服务间的异步交互（通过 RabbitMQ 代理交换消息）上。

图片来源：https://technology.lastminute.com/contract-testing-asynchronous-messaging-pact-junit-mockk/

eBay 的团队研究了基于OpenAPI规范的 API 定义语义版本控制，但得出的结论是，版本控制本身不足以解决系统测试的脆弱性。他们将BDD（行为驱动开发）视为描述 API 消费者需求的一种方式，生产者和消费者团队协作编写所有需求并使其可执行。事实证明，在采用这种方法时，API 提供方需要在客户需求发生变化时捕获和更新客户需求，而这已被证明是有问题的。

最后，他们发现了契约测试，生产者和消费者团队可以在他们的测试用例中使用 Mock（或存根）来独立地维护测试套件。

他们对Spring Cloud Contract和 Pact 进行了评估，最终选择了后者，因为后者可以更直接地使用 schema，并有更好的跨团队交互支持。他们对 Spring Cloud Contract 和 Pact 进行了评估，最终选择了后者，因为后者可以更直接地使用 schema，并有更好的跨团队交互支持。他们对Pactflow（一款商业版 Pact 产品）和内部 CI/CD 工具进行了无缝集成，并创建了一个专门的开发者门户，用于配置新的契约测试。

图片来源：https://tech.ebayinc.com/engineering/api-evolution-with-confidence-a-case-study-of-contract-testing-adoption-at-ebay/

Dell'Oro 强调，契约测试本身并不能完全替代系统级集成测试。契约测试旨在验证服务之间数据交换的正确性，但服务级集成测试会同时执行业务逻辑和错误处理，确保整个流程/数据流的正确性和弹性。

【声明：本文由 InfoQ 翻译，未经许可禁止转载。】

查看英文原文：https://www.infoq.com/news/2023/05/ebay-contract-testing-evolution/

延伸阅读：

测试驱动开发？还是测试驱动需求？

软件界旷世之架：测试驱动开发（TDD）之争