首页 > 代码库 > 契约测试(Pact)

契约测试(Pact)

    • 为什么要使用契约测试(Pact)

      目前开发过程中存在的问题
      联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行,要同时把握双方的进度,造成资源和时间上的浪费。
      对于接口的变动把控相当困难。由于接口变动是普遍存在的,尤其对于调用关系复杂的接口,一旦发生变动,如果没有一套机制进行控制,验证的成本巨大。更不必说持续集成了,只能成为空谈。
      
      契约测试能给我们带来什么
      通过使用契约测试,接口调用双方协商接口后就可以并行开发,并且在开发过程中就利用契约进行预集成测试,不用等到联调再来集成拉通接口,一旦成熟,在保证质量的前提下,联调的成本可以减低到几乎为0。
      因为契约的存在,让接口的变动有迹可循,即使变动也可以确保变动的安全性和准确性。
      与CI的集成是这一整套流程的关键,我们在构建的过程中来完成接口的联调测试,接口变动的验证测试。如果规范整个的开发流程,正确使用契约测试,就可以真正实现持续集成,来达到任何时候构建出来的程序都是真正可发布的状态。
      Pact工具非常的轻量化,易使用,学习成本低,带来的效果显著。
      
    • Pact 介绍

    • Pact 开发术语

      Consumer:微服务接口的调用者
      Provider:微服务接口的提供者
      契约:是由consumer端和provider端共同定义的接口规范,包括接口访问的路径,输入和输出数据。在具体的实施中,是由consumer端生成的一个json文件,并存放在pact broker上
      Pact Broker:保存契约文件的服务器

    • Pact 开发流程

      一.**制定契约**
      制定契约就是双方定义接口的过程,完成接口文档的编写。
      二.**接口双方的命名**

      这里的命名在后续写测试用例的时候需要使用
      三.**代码实现**

      四.**构建过程**
      Maven构建的过程会跑测试用例,所以可以自动完成契约文件的生成,上传broker,契约文件的验证等一系列过程
      这里要先构建consumer,用来确保先生成契约文件,以免provider的验证的时候取不到。
      provider构建时,会启动真实的服务来进行验证。
      完成各自构建,联调在出包的时候就已经完成,意味着构建后出的包就基本是一个可发布的状态。

契约测试(Pact)