微服务时代，你还没掌握契约测试吗_契约测试和集成测试区别

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

契约测试的作用：

• 测试接口和接口之间的正确性
• 验证服务层提供的数据是否是消费端所需要的
• 将本来需要在集成测试中体现的问题前移，更早的发现问题
• 更快速的验证消费端和提供端之间交互的基本正确性

02

为什么要存在契约测试

首先我们将使用以下示例模型来描述微服务测试背后的概念：

在上面的图中，我们可以看到有两个微服务，通过REST彼此进行通信。第一项服务扮演消费者的角色，第二项扮演提供者的角色。

当需要进行集成测试时，可以通过服务虚拟化来模拟正在与之通信的微服务。这里服务提供者被模拟，在部署消费者服务之前，您希望证明其能正常工作。当运行所有测试均为绿色您认为可以部署您的服务了。

但是，如果您针对生产提供商运行服务，而不是模拟版本，则有可能会失败。在这个例子中，提供者已经改变了数据格式。集成测试无法解决这个问题，因为它们正在针对Provider的过时版本运行。

**如何填补测试过程中的这个空白？**将引入消费者驱动契约测试的概念。消费者驱动契约测试方法是在消费者和提供者之间定义在它们彼此之间转移的数据格式。通常，合同的格式由消费者定义并与相应的提供商共享。之后，执行测试以验证契约是否相符。CDC测试的先决条件之一是可以与提供商服务团队保持良好的最佳密切沟通，分享这些契约和交流测试结果是实施适当的CDC测试的重要部分。

03

PACT测试框架

PACT是一个开源的CDC测试框架。它提供了广泛的语言支持，如Ruby，Java，Scala，.NET，Javascript，Swift/Objective-C。

PACT的工作原理

消费者作为数据的最终使用者非常清楚、明确的知道需要的什么样格式，什么类型的数据，它将负责创建契约文档（包含结构和格式的json文件），服务提供端将根据消费者端创建的契约文档提供对应格式的数据并返回给消费者，通过契约检查判断如果服务端提供的数据和消费者生成的契约不匹配，将抛出异常并提示给服务提供端。

04

Spring Cloud Contract

Spring Cloud Contract是一个基于消费者驱动契约的测试框架。它会基于契约来生成存根服务，消费方不需要等待接口开发完成，就可以通过存根服务完成集成测试。Spring Could Contract中，契约是用一种基于 Groovy 的 DSL 定义的。

谈到契约测试时，我们首先需要定义一个包含期望使用接口的第一个文件。作为标准PACT法则，契约必须由消费者服务来定义，但是在Spring Cloud Contract中，它实际上位于提供者服务代码中。在指南手册中包含了两个大步骤：

• 服务提供者

• 编写合同规范（Groovy DSL）

• 在Provider端生成自动验收测试

• 生成WireMock JSON存根＆将存根发布到Maven（本地）存储库

• 服务消费者

• 在消费者端配置Stub Runner

• 执行消费者测试 - Stub Runner嵌入了WireMock

• 检查验证结果

服务提供者

我们在服务端编写一个简单服务接口，判断数字是奇数还是偶数

@RestController

public class EvenOddController {

@GetMapping("/validate/prime-number") public String isNumberPrime(@RequestParam("number") Integer number) { return number % 2 == 0 ? "Even" : "Odd"; }}

• MAVEN 依赖

对于我们的提供者，我们需要spring-cloud-starter-contract-verifier依赖：

<dependency>

<groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-contract-verifier</artifactId> <scope>test</scope></dependency>

需要将我们的基础测试类的名称配置到spring-cloud-contract-maven-plugin：

<plugin>

<groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-contract-maven-plugin</artifactId> <version>1.2.2.RELEASE</version> <extensions>true</extensions> <configuration> <baseClassForTests>com.peterwanghao.spring.cloud.contract.producer.BaseTestClass        </baseClassForTests> </configuration></plugin>

• 基础测试类

需要在加载Spring上下文的测试包中添加一个基类：

`@RunWith(SpringRunner.class)@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.MOCK)@DirtiesContext@AutoConfigureMessageVerifier public class BaseTestClass {
@Autowired
private EvenOddController evenOddController;

@Before
public void setup() {
StandaloneMockMvcBuilder standaloneMockMvcBuilder = MockMvcBuilders.standaloneSetup(evenOddController);
RestAssuredMockMvc.standaloneSetup(standaloneMockMvcBuilder);
}}`

• 测试存根

在/src/test/ resources/contracts/目录中，我们将在groovy文件中添加测试存根。例如

`import org.springframework.cloud.contract.spec.Contract

Contract.make {
description “should return even when number input is even”
request {
method GET()
url(“/validate/prime-number”) {
queryParameters {
parameter(“number”, “2”)
}
}
}
response {
body(“Even”)
status 200
}}`

当我们运行构建时，运行 mvn clean install 插件会自动生成一个名为ContractVerifierTest的测试类，它扩展我们的BaseTestClass并将其放在/target/generated-test-sources/contracts/中。

测试方法的名称派生自前缀“ validate_”与我们的Groovy测试存根的名称连接。对于上面的Groovy文件，生成的方法名称将为“validate_shouldReturnEvenWhenRequestParamIsEven”。

我们来看看这个自动生成的测试类：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-HEVXHEfG-1713548337904)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！