如何用Pact进行微服务集成测试

原文连接
https://codefresh.io/docker-tutorial/how-to-test-microservice-integration-with-pact/

挑战：微服务集成测试

迁移到微服务对测试咱们的系统产生了新的挑战。理论上每一个微服务都应该是隔离的并能够独立操做。但在实践中一个服务若是没有其余部分一般没什么用。另外一方面 - 为一个服务拉起整个系统的拓扑进行测试抵消了微服务指望带来的模块化和封装。

挑战在于如何检验与其余服务集成后没有问题。咱们但愿越早越好。并且咱们不想将复杂的生产环境重现一遍。通常来讲这种检验是集成功能测试或叫端到端测试。但实际是当咱们的系统愈来愈复杂 - 端到端带来的收益越少。 大量的相互依赖致使误报和很长的执行周期。 使得测试变得很难管理与调试。

这甚至有一个测试金字塔理论（最初由Mike Cohn在他的著做‘Succeeding with Agile’中提到）讲述了为了优化你的投入，你须要更少的高层次的端到端测试，写更多的低层次的单元测试。

请阅读本文并看看Codefresh(https://codefresh.io/codefresh-signup/?utm_source=Blog&utm_medium=Post&utm_campaign=pactT)， 他是对于Docker最好的CI。

---

单元测试很好！但在它带来的全部收益中 - 他们对测试与其余服务的集成没什么做用。

那咱们怎样保证每一个服务团队能够独立的迭代但又能保证总体系统的健康呢？咱们如何实现持续交付，小批量生产，快速反馈，而又不会在每次变动时引发服务出问题呢？

一个可能的答案是Consumer-Driven Contract(CDC) 测试。这种测试策略是基于一种多年前就定义的服务进化模式。它如今分布式系统变得更常见后变得更适合了。

Consumer-Driven Contracts：

我尝试简单解释一下。 Consumer-Driven Contracts实际就是面向服务与服务关系的合约。意思就是不想之前是provider提供方定义接口与服务级别是什么样(同事消费者consumer尽可能适配) - 如今消费者来领舞。 每一个消费者来定义它指望服务提供方须要交付与须要检查的。这就将集成的责任转移到服务提供方。

那就变成如下流程：

在商务合约上者一般描述成‘将消费者放在第一位’ 或‘倾听你的客户’。由于想要提供最好的服务咱们须要尽可能作到客户指望和须要的。而不是咱们假设对的事。

当讨论微服务进化时 - 在那种每一个服务都有一个独立团队开发的大型企业里尤为重要。有时这些团队也可能在不一样的地理位置和区域。这影响了即时沟通和让业务功能进化更有挑战性。

合约测试框架

消费者驱动合约固然能够经过投资团队间的沟通与协做来管理。 也能够经过使用结构化的系列化格式如protobuf，thrift或messagepack消息体来解决。但若是要管理一个定义好的流程 - 最好使用框架，尤为若是是个开源的。

这种框架已经出现了。这其中最杰出和活跃的是Pact和Spring Cloud Contract。后者只针对使用JVM的项目。 而Pact使用Ruby写的但能够支持不少语言，包括Java，Go，Python，Javascript。 让它很适合在复杂，多样性的微服务系统中使用。

今天咱们会看看如何在两个服务间定义和校验合约。消费者服务是用Python写的。而提供方服务是用Go写的。测试会在咱们的CI/CD流程中进行 - 也就是在Codefresh流水线里面。

Pact

因此，Pact怎么工做的？它开始于消费者。

消费者服务的开发写一个测试。测试定义了与提供方的集成。这包括了提供方须要的状态，请求的消息体和指望的结果。基于这个定义Pact创建和运行一个提供方的桩来进行测试。这个测试的输出回事一个或多个json文件，通常是这样的：

{
  "consumer": {
    "name": "billy"
  },
  "provider": {
    "name": "bobby"
  },
  "interactions": [
    {
      "description": "My test",
      "providerState": "User billy exists",
      "request": {
        "method": "POST",
        "path": "/users/login",
        "headers": {
          "Content-Type": "application/json",
        },
        "body": {
          "username":"billy",
          "password":"issilly"
        }
      },
      "response": {
        "status": 200,
      }
    },
  ],
  "metadata": {
    "pactSpecification": {
      "version": "2.0.0"
    }
  }
}

这就是合约，这就是pact。 如今他们被传给服务提供方。也能够被提交给共享的git仓库，或经过Pact Broker应用上传到共享的文件存储。

一旦合约更新过了 - 提供方须要对其进行测试验证是否仍符合要求。它经过使用共享的pact文件运行它本身的校验测试而不是真实版本的服务。若是全部的交互是符合预期的并测试经过了 - 咱们就能够继续了。 若是不 - 提供方的开发须要通知消费方的开发。而后，他们能够一块儿分析什么致使了合约的失败。

本文来自微信公众号「麦芽面包，id「darkjune_think」
转载请注明。微信扫一扫关注公众号。
交流Email: zhukunrong@yeah.net