跳到主要内容

Spring Cloud Contract 简介

DeepSeek V3 中英对照 Introducing Spring Cloud Contract

Spring Cloud Contract 将 TDD 提升到了软件架构层面。它允许您执行消费者驱动和生产者驱动的契约测试。

历史​

在成为 Spring Cloud Contract 之前，该项目名为 Accurest。它由来自 (Codearte) 的 Marcin Grzejszczak 和 Jakub Kubrynski 创建。

0.1.0 版本发布于 2015 年 1 月 26 日，并于 2016 年 2 月 29 日发布的 1.0.0 版本达到稳定状态。

为什么需要它？​

假设我们有一个由多个微服务组成的系统，如下图所示：

微服务架构

测试问题​

如果我们想要测试上一节图片左上角的应用，以确定它是否能与其他服务通信，我们可以采取以下两种方法之一：

  • 部署所有微服务并进行端到端测试。

  • 在单元测试和集成测试中模拟其他微服务。

两者都有其优势，但也存在许多缺点。

部署所有微服务并进行端到端测试

优势：

  • 模拟生产环境。

  • 测试服务间的真实通信。

缺点：

  • 要测试一个微服务，我们必须部署六个微服务、几个数据库以及其他组件。

  • 运行测试的环境被锁定，仅供一套测试使用（在此期间，其他任何人都无法运行测试）。

  • 测试运行耗时很长。

  • 反馈在流程后期才出现。

  • 调试极其困难。

在单元测试和集成测试中模拟其他微服务

优势：

  • 它们提供非常快速的反馈。

  • 它们没有基础设施要求。

缺点：

  • 服务的实现者可能会创建与实际情况无关的存根。

  • 你可能会带着通过的测试和失败的生产环境进入生产阶段。

为了解决上述问题，Spring Cloud Contract 应运而生。其主要理念是提供极速反馈，而无需搭建整个微服务世界。如果你使用存根（stubs），那么你只需要那些你的应用程序直接使用的应用。下图展示了存根与应用程序之间的关系：

Stubbed Services

Spring Cloud Contract 确保您使用的存根是由您调用的服务创建的。此外，如果您能够使用它们，这意味着它们已经通过了生产者端的测试。简而言之，您可以信任这些存根。

目的​

Spring Cloud Contract 的主要用途包括：

  • 确保HTTP和消息存根（在开发客户端时使用）的行为与实际服务器端实现完全一致。

  • 推广ATDD（验收测试驱动开发）方法以及微服务架构风格。

  • 提供一种发布契约变更的方式，使变更在双方都能立即可见。

  • 生成可在服务器端使用的样板测试代码。

默认情况下，Spring Cloud Contract 集成了 Wiremock 作为 HTTP 服务器桩。

important

Spring Cloud Contract 的目的不是在契约中编写业务功能。假设我们有一个欺诈检查的业务用例。如果用户可能因 100 种不同的原因被判定为欺诈，我们建议您创建两个契约：一个用于正向案例，一个用于负向案例。契约测试用于测试应用程序之间的契约，而不是模拟完整的行为。

什么是合约？​

作为服务的消费者，我们需要明确想要实现的目标。我们需要制定自己的期望。这就是我们编写契约的原因。换句话说，契约是关于API或消息通信应如何进行的协议。请看以下示例：

假设您想要发送一个包含客户公司ID及其希望向我们借款金额的请求。您还希望使用PUT方法将其发送到/fraudcheck URL。以下清单展示了用于检查客户是否应被标记为欺诈的合约，分别以Groovy和YAML格式呈现：

important

预期合约来自可信来源。你绝不应下载或与来自不可信位置的合约进行交互。