01 契约测试：微服务时代的“防弹衣”
微服务架构下，每个服务独立开发、独立部署。但问题来了：A服务改了接口，B服务不知道。等到联调才发现，返工成本是修改成本的10倍。
传统方案是什么？集成测试。启动所有服务，跑一遍全链路。但集成测试有三大死穴：
- ►慢：启动100个服务，等30分钟
- ►脆：一个服务挂了，全盘失败
- ►贵：维护测试环境，烧钱如流水
契约测试就是来终结这个噩梦的。它不启动服务，只验证“契约”——服务间通信的协议。像签合同一样，双方约定输入输出，各自遵守。
Spring Cloud Contract是契约测试的标杆工具。它提供两大核心能力：
- ►消费者驱动契约：消费方定义期望，提供方实现
- ►自动生成测试：基于契约生成Stub和验证用例
数据说话：Netflix使用契约测试后，服务间兼容问题减少80%，部署频率提升3倍。
契约不是约束，是自由的边界。
02 手把手：Spring Cloud Contract从0到1
环境准备：
- ►JDK 11+
- ►Maven 3.6+
- ►Spring Boot 2.7+
步骤1：创建契约项目
xml
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-contract-verifier</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-stub-runner</artifactId>
<scope>test</scope>
</dependency>
步骤2：定义契约文件
在src/test/resources/contracts/目录下创建shouldReturnUser.groovy：
groovy
Contract.make {
description "获取用户信息"
request {
method GET()
url "/api/users/1"
headers {
contentType applicationJson()
}
}
response {
status OK()
headers {
contentType applicationJson()
}
body([
id: 1,
name: "张三",
email: "zhangsan@test.com"
])
}
}
步骤3：配置契约验证
在application.yml中：
yaml
stubrunner:
ids: 'com.example:user-service:+:stubs:8080'
stubs-mode: local
步骤4：生成测试用例
运行Maven命令：
bash
mvn clean install -DskipTests
Spring Cloud Contract自动生成测试类：
java
public class UserServiceContractTest extends BaseTestClass {
@Test
public void shouldReturnUser() {
// 自动生成的测试代码
given().spec(requestSpecification)
.get("/api/users/1")
.then()
.statusCode(200)
.body("id", equalTo(1))
.body("name", equalTo("张三"));
}
}
自动化不是偷懒，是让机器干机器的事。
03 实战：消费者驱动契约的威力
真实场景：订单服务需要调用用户服务获取用户信息。
消费者定义契约
订单服务团队编写shouldReturnUser.groovy，明确期望：
groovy
Contract.make {
description "订单服务获取用户信息"
request {
method GET()
url "/api/users/1"
}
response {
status OK()
body([
id: 1,
name: "张三",
phone: "13800138000" // 新增字段：电话
])
}
}
提供方实现契约
用户服务团队收到契约后，实现接口：
java
@RestController
public class UserController {
@GetMapping("/api/users/{id}")
public User getUser(@PathVariable Long id) {
return userService.findById(id);
}
}
自动验证
运行验证测试：
如果用户服务返回的字段与契约不符，测试立即失败。错误信息精确到字段级别：
text
Expected: {id: 1, name: "张三", phone: "13800138000"}
Actual: {id: 1, name: "张三"}
持续集成集成
在CI流水线中加入契约验证：
yaml
stages:
- build
- contract-test
- deploy
contract-test:
stage: contract-test
script:
- mvn clean verify
artifacts:
paths:
- target/stubs/
失败要快，快才能改。
04 进阶：契约测试的3个黄金法则
法则1：契约即文档
契约文件就是API文档。用Groovy DSL描述，人类可读，机器可验证。
groovy
Contract.make {
description "创建订单"
request {
method POST()
url "/api/orders"
body([
userId: 1,
productId: 100,
quantity: 2
])
}
response {
status CREATED()
body([
orderId: 12345,
status: "PENDING"
])
}
}
法则2：版本化契约
每个服务版本对应一套契约。使用git标签管理：
bash
git tag v1.0.0-contract
git tag v2.0.0-contract
法则3：契约测试覆盖率
不是所有接口都需要契约测试。只测试关键路径：
覆盖率目标：核心接口100%，整体60%以上。
二八法则：20%的接口承担80%的风险。
05 避坑指南：契约测试的5个常见陷阱
陷阱1：契约太复杂
错误做法：一个契约文件包含所有场景。
正确做法：每个场景一个文件，清晰分离。
text
contracts/
├── shouldReturnUser.groovy
├── shouldReturnUserNotFound.groovy
└── shouldReturnUserList.groovy
陷阱2：忽略边界情况
错误做法：只测试正常路径。
正确做法：测试异常场景。
groovy
Contract.make {
description "用户不存在"
request {
method GET()
url "/api/users/999999"
}
response {
status NOT_FOUND()
body([
error: "用户不存在"
])
}
}
陷阱3：契约更新不及时
错误做法：改了接口，忘了更新契约。
正确做法：把契约更新纳入开发流程。
bash
# 修改代码前，先更新契约
git checkout -b feature/update-contract
# 修改契约文件
# 提交契约
git commit -m "更新用户接口契约"
# 再改代码
陷阱4：忽略性能契约
错误做法：只验证功能，不验证性能。
正确做法：在契约中加入响应时间约束。
groovy
Contract.make {
description "获取用户信息（性能要求）"
request {
method GET()
url "/api/users/1"
}
response {
status OK()
headers {
responseTime lessThan 200 // 响应时间<200ms
}
}
}
陷阱5：手动管理Stub
错误做法：手动创建Stub。
正确做法：从契约自动生成Stub。
xml
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<configuration>
<contractsDirectory>${project.basedir}/src/test/resources/contracts</contractsDirectory>
<baseClassMappings>
<baseClassMapping>
<contractPackageRegex>.*</contractPackageRegex>
<baseClassFQN>com.example.BaseTestClass</baseClassFQN>
</baseClassMapping>
</baseClassMappings>
</configuration>
</plugin>
工具是死的，人是活的。规则是死的，场景是活的。
---
测试不是终点，是起点。契约不是枷锁，是桥梁。 当你用Spring Cloud Contract把每个服务间的约定写进代码，兼容性问题不再是“找bug”，而是“对答案”。今天开始，让机器替你盯着接口变化，把时间还给真正的业务逻辑。
声明：本站部分稿件版权来源于网络，如有侵犯版权，请及时联系我们。
