契约测试--pact框架使用 - 简书
背景
最近刚换城市,忙于找工作,趁着等待面试结果的间隙给自己充充电。把之前一直很好奇的“微服务测试”学习了一番,了解了一个新的概念----契约测试。
接口的契约
对于一个api接口,一般会有接口文档说明。文档中会规定如何调用该接口、如何传参,以及接口会如何响应。其实这个就可以理解为接口的"契约"。前端按照这个“契约”去调用,服务端按照“契约”返回响应的内容。若服务端擅自修改了返回内容结构,就算作违反"契约",也是造成bug的一个原因。
扩展到微服务当中,每个服务与服务之间的调用,同样需要遵守这种"契约",才能保证接口功能的稳定性。
什么是契约测试?
微服务架构中,一般分为“提供者”(provider,提供接口的服务) 和“消费者”(consumer,调用接口的服务)
接口文档可以称之为对接口契约的具体描述,主要提供给人看。而契约测试,则是将契约具象为代码/工具可识别的形式,比如json、yml、DSL格式。然后借助相关测试工具,根据这份契约,自动测试“消费者/提供者”接口是否正常。
契约测试一般分两种,一种是消费者驱动,一种是提供者驱动。其中最常用的,是消费者驱动的契约测试(简称 CDC)。即由“消费者”定义出接口“契约”,然后测试“提供者”的接口是否符合契约。
契约测试工具使用--PACT
契约测试工具貌似有不少,此处介绍一个常用工具--- PACT。
pact是一个契约测试框架,目前支持java、python、ruby等多种语言。
pact契约测试分为两步:
- 编写test用例,生成契约文件(不需要启动服务)。
- 利用pact-verifier命令和契约文件,验证接口提供者是否正确 (需要启动提供者服务)
以下为demo示例:
1、服务A,提供者
import json
from flask import Flask
app = Flask(__name__)
@app.route('/')
def get_info():
info = {
"name": "zhangsan",
"age": 20
}
return json.dumps(info)
if __name__ == '__main__':
app.run(port=8080)
2、服务B,消费者。(调用服务A的接口)
import json
import requests
from flask import Flask
app = Flask(__name__)
@app.route('/')
def show_info():
res = requests.get("http://localhost:8080/").json()
result = {
"code":0,
"msg":"ok",
"data": res
}
return json.dumps(result)
if __name__ == '__main__':
app.run(port=8081)
3、测试用例,用于生成契约文件
import atexit
import requests
import unittest
from pact.consumer import Consumer
from pact.provider import Provider
# 定义一个pact,消费者是ModuleB,生产者是ModuleA,契约文件存放在pacts文件夹下
pact = Consumer('ModuleB').has_pact_with(Provider('ModuleA'), pact_dir='./pacts')
# 启动服务
pact.start_service()
atexit.register(pact.stop_service)
# 测试用例
class UserTesting(unittest.TestCase):
def test_service(self):
# 消费者定义的期望结果
expected = {"name": "zhangsan", "age": 20}
# 消费者定义的契约的实际内容。包括请求参数、请求方法、请求头、响应值等
(pact
.given('test service.')
.upon_receiving('a request for serviceB')
.with_request('get', '/')
.will_respond_with(200, body=expected))
# pact自带一个mock服务,端口 1234
# 用requests向mock接口发送请求,验证mock的结果是否正确
with pact:
res = requests.get("http://localhost:1234").json()
self.assertEqual(res, expected)
if __name__ == "__main__":
ut = UserTesting()
ut.test_service()
4、实际生成的契约文件 moduleb-modulea.json
{
"consumer": {
"name": "ModuleB"
},
"provider": {
"name": "ModuleA"
},
"interactions": [
{
"description": "a request for serviceB",
"providerState": "test service.",
"request": {
"method": "get",
"path": "/"
},
"response": {
"status": 200,
"headers": {
},
"body": {
"name": "zhangsan",
"age": 20
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}
}
5、根据契约文件,验证服务A是否正确
a. 启动服务A(提供者)
b. 执行 pact-verifier --provider-base-url=http://127.0.0.1:8080 --pact-url=./pacts/moduleb-modulea.json
,即可验证接口是否符合契约
契约测试的优点
- 在开发接口前定义好契约,消费者和提供者可以并行开发。根据契约可以很容易自测,不必等到联调时才暴露问题
- 确保变动的安全性和准确性。只要有变化,契约测试即可第一时间发现
- 契约文件可以直观追踪接口的变化
- 可以将契约测试集成到CI中
- 每次只测试单个服务,更容易定位问题
- 来自于模拟服务的可靠响应能够降低测试的不稳定性
契约测试与接口测试的区别
契约测试与接口测试的原理都是一样的,都是发送请求、验证响应结果。但是接口测试更多的关注业务api的功能、逻辑,而契约测试主要关注接口是否符合“契约”,监控接口的变动。
契约测试相当于将测试工作前移,在开发阶段就能自测。并且契约测试更加轻量级。