通用技术 关于契约测试的疑问

Elsie · 2021年02月02日 · 最后由 Elsie 回复于 2021年02月03日 · 579 次阅读

最近接触到契约测试,个人感觉还是挺有用的,不知道大家有没有在实际工作中使用?
可行性和适用性怎么样

共收到 7 条回复 时间 点赞

可以先统计下,发现的缺陷里有多少是可以通过这个契约测试发现的?

每个团队不大一样,关键还是看自己是否适用。我之前所在团队由于契约都是封装成 rpc 调用,每次升级只新增,不改旧的,确保向下兼容,所以不大需要专门做契约测试。

研究过,还没落地,契约测试本身难度不高,更多的是流程规范问题,谁来维护这个契约,什么时候使用

陈恒捷 回复

可以多说一下 契约都是封装成 rpc 调用吗? 想了解一下 谢谢

小酷 回复

When all you have is a hammer everything looks like a nail... 官网说的😂

Elsie 回复

就是服务间调用都是封装成 rpc ,provider 把接口以独立 api 包形式提供给 consumer,consumer 引入后直接调用 api 包里提供的函数方法。可以参考下 dubbo 。

个人理解,系统间契约,基本就是客户端 - 服务端、服务端 - 服务端、内部系统 - 外部第三方三种场景。

第一种基本上会从设计层面确保向下兼容(客户端多版本并存特性决定必须这么做),比如只增不删不改。
第三种依赖第三方,一般上线后除非第三方变化,否则也不怎么会动
第二种数量最多,也最容易出现契约测试里提到的问题(一个接口 n 个服务调用,怎么确保调整后不影响其他服务)。但通过 rpc 调用,隐藏实际报文细节,再加上类似第一种的设计方式,也基本能保障不会因为某次改动影响其他服务,即使影响,只要大家更新 api 包,编译时就会发现和修正,也不用特意去测试。

所以说实话,个人没太想到契约测试在实际项目中能解决什么问题。不过这个只是我自己接触项目的情况,建议你可以结合你们实际项目中发现的问题,分析下有哪类问题是契约测试可以提前发现并解决的,如果发现有不少,也是可以去尝试落地的。

陈恒捷 回复

嗯嗯 感谢大佬回答 我去了解一下🎁

Elsie 关闭了讨论 02月03日 05:44
Elsie 重新开启了讨论 02月03日 05:45
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册