python expect模块_微服务下的契约测试—Python版

契约测试的背景

随着敏捷流程和DevOps的盛行，大项目的发版上线流程变得越来越笨重，在这种要求快速发布快速迭代的项目里，微服务的优势凸显无疑。 一个大项目按照功能或者分类等某一类共性拆成多个子组件，每个组件独立维护、测试、发布，敏捷流程容易推动，开发、测试、产品的工作也相对轻松。原本可能一个月只能发2个版本的产品，在微服务架构下可能发N个版本。

微服务架构下的困境

微服务架构固然有自己天然的优势，不过微服务架构特点，也给开发测试带来了不小的挑战： - 第一，维护成本的提升。原来3个大的系统，现在变成了30个功能代码组件，每个组件需要专人维护，需要提供稳定测试环境，关联查找和分析是一件麻烦事； - 第二，系统复杂性的提升。接上，彼此之间的调用关系指数级上升，原先一个接口的调用可能只会涉及到2个系统，在微服务的架构下，会调用10+的组件，复杂性较高。基于此，想要维护一套完整的、不受干扰的测试环境很难实现

传统接口测试的局限性

大部分场景下面，我们通常依靠接口测试来测试系统级的接口功能正确性，但在微服务背景下，接口测试有较大的局限性。

一，需要一套完整的测试环境；

二，接口测试用例的冗余度指数级增加，原本大模块设计出来的用例，在微服务下面需要针对每个组件都得单独设计测试用例，设计、维护、调用成本都会变得很高；

三，测试用例设计要求高，理论上用例需要覆盖到存在调用关系的所有逻辑分支，这需要你对组件调用关系有很清晰的了解。

契约测试

为了解决传统接口测试在微服务结构下的局限性，引入契约测试是很有必要的。

契约测试，Consumer Driven Contracts testing，消费者驱动测试。

在契约测试的理念下，只有两个对象：生产者和消费者，也就是调用者和被调用者，即细化到最小的一个系统组件。契约测试最精髓的思想是测试左移，测试只需要提供组件级的测试用例即可，执行全部交给开发和CI即可。 契约测试可靠吗？是可靠地，前提是大家在契约测试上达成共识，即无论微服务下面有多少组件，只要每个组件完成各自的契约测试，我们就有理由相信，组件集成之后的服务的质量是可靠的。

实例说明

我们用实例更好的理解一下契约测试

• 1、有一个获取用户信息的接口 /user，参数name，调用地址：http://0.0.0.0:5000/user?name=zhoujielun，返回对应的个人信息普通的接口测试，从客户端出发，通过设计不同的参数组合尽可能的覆盖更多的逻辑分支，比如name=zhoujielun，name=123等等，为了说明契约测试，我们尽量简单说明使用unittest单测框架来做接口测试，我们关注接口的返回代码如 user_unittest.py所示

def test_lizeyang(self):
    """name=lizeyang的测试用例"""
    expect = { "age": 21, "home": "china"}
    res = requests.get("http://127.0.0.1:5000/user?name=lizeyang").json()
    self.assertEqual(res, expect)
def test_zhoujielun(self):
    """name=zhoujielun的测试用例"""
    expect = { "age": 21, "home": "america"}
    res = requests.get("http://127.0.0.1:5000/user?name=zhoujielun").json()
    self.assertEqual(res, expect)
    self.assertEqual(res, expect)

运行python user_unittest.py，结果如下：

======================================================================
FAIL: test_lizeyang (__main__.UserTesting)
name=lizeyang的测试用例
----------------------------------------------------------------------
Traceback (most recent call last):
  File "user_unittest.py", line 19, in test_lizeyang
    self.assertEqual(res, expect)
AssertionError: {u'errmsg': u'user not exist.'} != {'home': 'china', 'age': 21}
- {u'errmsg': u'user not exist.'}
+ {'age': 21, 'home': 'china'}
----------------------------------------------------------------------
Ran 2 tests in 0.015s
FAILED (failures=1)

可以看到，name=lizeyang的测试用例是失败的，预期结果和实际调用结果不相符

上面是一个简单的接口测试用例，对于普通服务的接口测试来说，这种测试方法是可行的，没有问题但是在微服务架构下，会遇到一个问题：某服务X改了接口返回的数据或者结构，比如原先的返回code字段变更成了status或者某个home字段的值，按照上面的测试方法，我们独立对X测试的时候，优先考虑的是X服务的可用性和正确性，很难去实际度量X的上游调用方他的代码在实际调用X接口的时候是否正常，服务他的预期，基于此，微服务的一个组件，他的上游组件数量是N多。

生产者按照自己的意愿去生产接口，导致这些接口无法满足消费者的需求，从而引发各种开发、测试问题，显然不是我们想要的结果。契约测试的出现就是为了解决这种需求与实际不对等的问题，本质上其实是一个基于mock服务的接口测试

通俗的契约测试核心思想：对于任意两个存在调用关系的服务组件A和B，A需要调用B的接口api_01，从契约的角度出发，我们需要从A这个消费者的角度制造一个契约（或者叫合同吧），合同里面约定了接口、接口入参以及在入参的前提接口应该给出什么样的返回。然后B组件的接口api_01在开发的时候需要按照契约的要求去开发，开发完成之后由B端人员发起契约测试或者CI集成测试

契约测试 = 测试左移 + mock + 接口测试

#!/usr/bin/python
# -*- encoding:utf-8 -*-
import atexit
import requests
import unittest
from pact import EachLike, SomethingLike, Term
from pact.consumer import Consumer
from pact.provider import Provider
# 定义一个pact，消费者是ModuleA，生产者是ModuleB，契约文件存放在pacts文件夹下
pact = Consumer('ModuleA').has_pact_with(Provider('ModuleB'), pact_dir='./pacts’)
# 启动服务
pact.start_service()
atexit.register(pact.stop_service)

class UserTesting(unittest.TestCase):
    def runTest(self):
        self.test_lizeyang()
    def test_lizeyang(self):
        # 预期结果
        expected = {"age": 222, "home": "china"}
        # 契约的实际内容
        (pact
         .given('test lizeyang this user.')
         .upon_receiving('a request for the user `lizeyang`')
         .with_request('get', '/user', query={"name": "lizeyang"})
         .will_respond_with(200, body=expected))
        # 调用pact自带的mock服务，注册接口
        with pact:
            res = requests.get("http://localhost:1234/user?name=lizeyang").json()
        self.assertEqual(res, expected)

if __name__ == "__main__":
    ut = UserTesting()
    ut.test_lizeyang()

运行python user_pact_test.py之后，

INFO  WEBrick 1.3.1
INFO  ruby 2.2.2 (2015-04-13) [x86_64-darwin13]
INFO  WEBrick::HTTPServer#start: pid=63533 port=1234
{u'home': u'china', u'age': 222}
INFO  going to shutdown ...
INFO  WEBrick::HTTPServer#start done.

这时，在contracts/pacts文件夹下会自动生产一个契约文件modulea-moduleb.json，内容如下。

{
  "consumer": {
    "name": "ModuleA"
  },
  "provider": {
    "name": "ModuleB"
  },
  "interactions": [
    {
      "description": "a request for the user `lizeyang`”,  # 描述
      "providerState": "test lizeyang this user.”,
      "request": {
        "method": "get",
        "path": "/user",
        "query": "name=lizeyang"
      },
      "response": {
        "status": 200,
        "headers": {
        },
        "body": {
          "home": "china",
          "age": 222
        }
      }
    }
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

这个契约文件定义了调用生产者ModuleB时候的测试用例和返回报文的格式 B端拿到这份契约之后，需要按照个契约的内容完成接口开发以及自测 自测方法：

pact-verifier --provider-base-url=http://127.0.0.1:5000 --pact-url=./contracts/pacts/test_sender-service_001.json

可以看到自测接口与实际的返回是不一致的，开发需要按照契约修改自己的代码来通过契约测试即可。 至此，这个Python的契约测试实例就完成了，当然了契约测试的内容不仅仅只有这样，还包括契约测试的数据文件和版本管理，这个后面有机会再单独讲讲吧。