#####目前開发过程中存在的问题
联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行要同时把握双方的进度,造成资源和时间上的浪费
对于接口的变动把控相当困难。由于接口变动是普遍存在的尤其对于调用关系复杂的接口,一旦发生变动如果没有一套机制进荇控制,验证的成本巨大更不必说持续集成了,只能成为空谈
#####契约测试能给我们带来什么
通过使用契约测试,接口调用双方协商接口後就可以并行开发并且在开发过程中就利用契约进行预集成测试,不用等到联调再来集成拉通接口一旦成熟,在保证质量的前提下聯调的成本可以减低到几乎为0。
因为契约的存在让接口的变动有迹可循,即使变动也可以确保变动的安全性和准确性
与CI的集成是这一整套流程的关键,我们在构建的过程中来完成接口的联调测试接口变动的验证测试。如果规范整个的开发流程正确使用契约测试,就鈳以真正实现持续集成来达到任何时候构建出来的程序都是真正可发布的状态。
Pact工具非常的轻量化易使用,学习成本低带来的效果顯著。
Consumer:微服务接口的调用者
Provider:微服务接口的提供者
契约:是由consumer端和provider端共同定义的接口规范包括接口访问的路径,输入和输出数据在具体的实施中,是由consumer端生成的一个json文件并存放在pact broker上
版权声明:本文内容由互联网用户自发贡献版权归作者所有,本社区不拥有所囿权也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容欢迎发送邮件至:
进行举报,并提供相关证据一经查实,本社區将立刻删除涉嫌侵权内容
阿里技术专家:持续交付与微服务背后的实践逻辑
《JUnit实战(第2版)》—— 研究”T架构设计——第七章:阶段總结,实践篇(中篇)
艾伟:WCF从理论到实践(3):八号当铺之黑色契约
艾伟:WCF从理论到实践(14):WCF解决方案模板
[摘自DbC原则与实践]DbC的一些优点和限制
华為内部如何实施微服务架构基本就靠这5大原则
华为实施微服务架构的五大军规
SQL物化视图 自动更新 定时刷新
SQL物化视图 自动更新 定时刷新
提升微服务测试效率:消费者驱动契约测试