契约测试--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的功能、逻辑，而契约测试主要关注接口是否符合“契约”，监控接口的变动。
契约测试相当于将测试工作前移，在开发阶段就能自测。并且契约测试更加轻量级。

参考

微服务下的契约测试 (CDC) 解读
契约测试之核心解惑
Pact中文参考指南