|
此版本仍在开发中，尚不被认为是稳定的。对于最新的稳定版本，请使用 spring-cloud-contract 4.3.0！ |
Spring Cloud Contract 简介
Spring Cloud Contract 将 TDD 提升到了软件架构的层面。 它允许您执行消费者驱动和生产者驱动的合同测试。
历史
在成为 Spring Cloud Contract 之前，这个项目被称为 Accurest。 它是由 （Codearte） 的 Marcin Grzejszczak 和 Jakub Kubrynski 创建的。
这0.1.0发布于 2015 年 1 月 26 日，并随着1.0.02016 年 2 月 29 日发布。
测试问题
如果我们想在前面的图像左上角测试应用程序 部分来确定它是否可以与其他服务通信，我们可以执行以下作之一 两件事：
-
部署所有微服务并执行端到端测试。
-
在单元测试和集成测试中模拟其他微服务。
两者都有其优点，但也有很多缺点。
部署所有微服务并执行端到端测试
优势：
-
模拟生产。
-
测试服务之间的真实通信。
弊：
-
要测试一个微服务，我们必须部署六个微服务、几个数据库、 和其他项目。
-
运行测试的环境被锁定为一套测试（没有其他人 将能够同时运行测试）。
-
它们需要很长时间才能运行。
-
反馈在这个过程中很晚才出现。
-
它们极难调试。
在单元测试和集成测试中模拟其他微服务
优势：
-
他们提供非常快速的反馈。
-
它们没有基础设施要求。
弊：
-
服务的实现者创建可能与 现实。
-
您可以通过通过测试和失败的生产进入生产环境。
为了解决上述问题，创建了 Spring Cloud Contract。主要思想是 给你非常快的反馈，无需设置 微服务的整个世界。如果您处理存根，那么您唯一需要的应用程序 是应用程序直接使用的那些。下图显示了关系 存根数：
Spring Cloud Contract 为您提供了您使用的存根的确定性 由调用的服务创建。另外，如果你可以使用它们，那就意味着它们 针对制片方进行了测试。简而言之，您可以信任这些存根。
目的
Spring Cloud Contract 的主要用途是：
-
确保 HTTP 和消息存根（在开发客户端时使用）准确执行 实际的服务器端实现的作用。
-
推广ATDD（验收测试驱动开发）方法和微服务架构风格。
-
提供一种发布合同更改的方法，这些更改在双方都立即可见。
-
生成要在服务器端使用的样板测试代码。
默认情况下，Spring Cloud Contract 与 Wiremock 集成为 HTTP 服务器存根。
| Spring Cloud Contract 的目的不是开始编写业务合同中的功能。假设我们有一个欺诈检查的业务用例。如果一个用户可能因为 100 种不同的原因而成为欺诈者，我们假设您将创建两个合约，一个用于正面情况，一个用于负面情况。合约测试是用于测试应用程序之间的合约，而不是模拟完整的行为。 |
什么是合同？
作为服务的消费者，我们需要定义我们到底想要实现什么。我们需要制定我们的期望。这就是我们编写合约的原因。换句话说，合约是关于 API 或消息通信应如何外观的协议。考虑以下示例：
假设您要发送一个请求，其中包含客户公司的 ID 和它想从我们这里借入的金额。您还想将其发送到/fraudcheckURL 通过使用 这PUT方法。 以下列表显示了一个合约，用于检查客户端是否应该在 Groovy 和 YAML 中被标记为欺诈：
| 预计合约来自可信来源。切勿下载来自不受信任位置的合约，也不应与之交互。 |