引入 Spring Cloud Contract
Spring Cloud Contract 将测试驱动开发（TDD）提升到了软件架构的层面。它允许您执行消费者驱动和生产者驱动的契约测试。
历史
在成为 Spring Cloud Contract 之前，该项目曾名为 Accurest。它由 Marcin Grzejszczak 和 Jakub Kubrynski（来自 Codearte）创建。
版本 0.1.0 的发布于 2015 年 1 月 26 日进行，随后在 2016 年 2 月 29 日发布的 1.0.0 版本中趋于稳定。
测试问题
如果我们想测试前一节图片左上角的应用程序，以确定它能否与其他服务通信，我们可以采取以下两种方法之一：
-
部署所有微服务并执行端到端测试。
-
在单元测试和集成测试中模拟其他微服务。
两者各有其优势，但也存在许多劣势。
部署所有微服务并执行端到端测试
优势：
-
模拟生产环境。
-
测试服务之间的实际通信。
缺点：
-
要测试一个微服务，我们必须部署六个微服务、若干数据库及其他组件。
-
测试运行的环境在单个测试套件运行期间被锁定（在此期间其他人无法运行测试）。
-
它们运行需要很长时间。
-
反馈在流程中来得非常晚。
-
它们极难调试。
在单元测试和集成测试中模拟其他微服务
优势：
-
它们提供非常快速的反馈。
-
它们没有基础设施要求。
缺点：
-
服务的实现者创建的存根可能与现实毫无关联。
-
你可以通过测试但生产环境失败的情况下上线。
为了解决上述问题，Spring Cloud Contract 应运而生。其核心思想是，在无需搭建整个微服务生态系统的情况下，为您提供极快的反馈。如果您正在使用存根（stubs），那么您只需启动那些您的应用直接依赖的应用程序即可。下图展示了存根与应用程序之间的关系：
Spring Cloud Contract 使您能够确信，您所使用的存根（stubs）是由您调用的服务创建的。此外，如果可以使用这些存根，说明它们已在生产者端（producer’s side）经过测试。简而言之，您可以信赖这些存根。
目的
Spring Cloud Contract 的主要目的包括：
-
为了确保HTTP和消息存根（在开发客户端时使用）能够完全执行实际服务器端实现的功能。
-
为了推广ATDD（验收测试驱动开发）方法以及微服务架构风格。
-
提供一种方式，以发布合同中的变更，使双方都能立即看到这些变更。
-
生成用于服务器端使用的样板测试代码。
默认情况下，Spring Cloud Contract 将 Wiremock 集成作为 HTTP 服务器存根。
| Spring Cloud Contract 的目的并非是在契约中开始编写业务功能。假设我们有一个欺诈检查的业务用例。如果用户可能因 100 种不同原因被判定为欺诈，我们假定您会创建两个契约：一个用于正向情况（即未检测到欺诈），另一个用于负向情况（即检测到欺诈）。契约测试用于测试应用之间的契约，而非模拟完整的系统行为。 |
什么是合同？
作为服务的消费者，我们需要明确我们究竟希望实现什么目标。我们需要制定我们的期望。这就是为什么我们要编写契约。换句话说，契约是关于API或消息通信应如何呈现的协议。考虑以下示例：
假设您希望发送一个包含客户公司ID及它欲向我们借款金额的请求。同时，您希望使用 PUT 方法将该请求发送至 /fraudcheck URL。以下列表展示了在 Groovy 和 YAML 中用于检查客户是否应被标记为欺诈行为的契约：
| 预期合约来自一个可信来源。您永远不应从不可信位置下载或与合约进行交互。 |