首页 > 代码库 > 契约测试(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)
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。