抢先一步
VMware 提供培训和认证，以加速您的进度。
了解更多Spring Cloud Contract4.1.3
Spring Cloud Contract 是一个包含解决方案的伞形项目，帮助用户成功实施消费者驱动契约方法。目前，Spring Cloud Contract 包含 Spring Cloud Contract Verifier 项目。
Spring Cloud Contract Verifier 是一个工具，支持基于 JVM 的应用程序的消费者驱动契约 (CDC) 开发。它附带用 Groovy 或 YAML 编写的契约定义语言 (DSL)。契约定义用于生成以下资源
-
默认情况下，JSON 存根定义将由 WireMock（HTTP 服务器存根）在对客户端代码（客户端测试）进行集成测试时使用。仍然必须手动编写测试代码，测试数据由 Spring Cloud Contract Verifier 生成。
-
如果你正在使用一个，则为消息传递路由。我们正在与 Spring Integration、Spring Cloud Stream 和 Apache Camel 集成。但是，如果你愿意，可以设置自己的集成。
-
验收测试（默认情况下在 JUnit 或 Spock 中）用于验证 API 的服务器端实现是否符合契约（服务器测试）。完整测试由 Spring Cloud Contract Verifier 生成。
Spring Cloud Contract Verifier 将 TDD 提升到了软件架构级别。
要了解 Spring Cloud Contract 如何支持其他语言，只需查看这篇博客文章。
功能
在尝试测试与其他服务通信的应用程序时，我们可以采取以下两种措施之一
-
部署所有微服务并执行端到端测试
-
在单元/集成测试中模拟其他微服务
两者都有各自的优点，但也有很多缺点。让我们关注后者。部署所有微服务并执行端到端测试
优点
-
模拟生产
-
测试服务之间的真实通信
缺点
-
要测试一个微服务，我们必须部署 6 个微服务、几个数据库等。
-
进行测试的环境将被锁定用于一组测试（即在此期间其他人无法运行测试）。
-
运行时间长
-
反馈非常迟
-
极其难以调试
在单元/集成测试中模拟其他微服务
优点
-
反馈非常快
-
没有基础设施要求
缺点
-
服务的实现者创建存根，因此它们可能与现实无关
-
你可以带着通过的测试进入生产，但生产失败
为了解决上述问题，创建了带有 Stub Runner 的 Spring Cloud Contract Verifier。其主要思想是提供非常快速的反馈，而无需设置整个微服务世界。
Spring Cloud Contract Verifier 功能
-
确保 HTTP/消息存根（在开发客户端时使用）执行实际服务器端实现将执行的操作
-
推广验收测试驱动开发方法和微服务架构风格
-
提供一种发布合同更改的方法，以便在通信的两侧立即可见
-
生成在服务器端使用的样板测试代码
Spring Boot 配置
在生产者端
要开始使用 Spring Cloud Contract，可以将使用 Groovy DSL 或 YAML 表达的 REST 或消息合同的文件添加到 contracts 目录中，该目录由 contractsDslDir 属性设置。默认情况下，它是 $rootDir/src/test/resources/contracts。
然后，可以将 Spring Cloud Contract Verifier 依赖项和插件添加到构建文件中，如下例所示
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-verifier</artifactId>
<scope>test</scope>
</dependency>
以下清单显示了如何添加插件，该插件应位于文件的 build/plugins 部分
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
</plugin>
运行 ./mvnw clean install 会自动生成测试，以验证应用程序是否符合添加的合同。默认情况下，测试在 org.springframework.cloud.contract.verifier.tests 下生成。
由于尚未实现合同所描述的功能，因此测试失败。
要使其通过，必须添加处理 HTTP 请求或消息的正确实现。此外，还必须向项目添加一个自动生成测试的基本测试类。此类由所有自动生成的测试扩展，并且它应包含运行它们所需的所有设置信息（例如 RestAssuredMockMvc 控制器设置或消息测试设置）。
以下示例来自 pom.xml，展示了如何指定基本测试类
<build>
<plugins>
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${spring-cloud-contract.version}</version>
<extensions>true</extensions>
<configuration>
<baseClassForTests>com.example.contractTest.BaseTestClass</baseClassForTests>
</configuration>
</plugin>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
信息：baseClassForTests 元素允许您指定基本测试类。它必须是 spring-cloud-contract-maven-plugin 中配置元素的子元素。
一旦实现和测试基本类就绪，测试通过，应用程序和存根工件都会构建并安装在本地 Maven 存储库中。您现在可以合并更改，并且可以在在线存储库中发布应用程序和存根工件。
在消费者端
您可以在集成测试中使用 Spring Cloud Contract Stub Runner 来获取正在运行的 WireMock 实例或模拟实际服务的消息路由。
要执行此操作，请添加对 Spring Cloud Contract Stub Runner 的依赖，如下例所示
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-stub-runner</artifactId>
<scope>test</scope>
</dependency>
您可以通过两种方式在 Maven 存储库中安装生产者端的存根
通过签出生产者端存储库并添加合约并通过运行以下命令生成存根
$ cd local-http-server-repo
$ ./mvnw clean install -DskipTests
测试被跳过，因为生产者端的合约实现尚未就绪，因此自动生成的合约测试失败。
通过从远程存储库获取已存在的生产者服务存根。要执行此操作，请将存根工件 ID 和工件存储库 URL 作为 Spring Cloud Contract Stub Runner 属性传递，如下例所示
stubrunner:
ids: 'com.example:http-server-dsl:+:stubs:8080'
repositoryRoot: https://repo.spring.io/libs-snapshot
现在，您可以使用 @AutoConfigureStubRunner 为测试类添加注释。在注释中，提供 Spring Cloud Contract Stub Runner 的 group-id 和 artifact-id 值，以便为您运行协作者的存根，如下例所示
@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment=WebEnvironment.NONE)
@AutoConfigureStubRunner(ids = {"com.example:http-server-dsl:+:stubs:6565"},
stubsMode = StubRunnerProperties.StubsMode.LOCAL)
public class LoanApplicationServiceTests {
从在线存储库下载存根时使用 REMOTE stubsMode，离线工作时使用 LOCAL。
现在，在集成测试中，您可以接收协作者服务预计发出的 HTTP 响应或消息的存根版本。