接口测试 契约测试 vs 基于契约的测试

Martin · September 18, 2019 · Last by Martin replied at September 27, 2019 · 811 hits

概念不难, 描述很绕, 导致感觉很烧脑, 尝试简单整理一下, 不清晰的话在整理一遍

https://www.jianshu.com/p/ca82cde5b125

共收到 3 条回复 时间 点赞
残枫 testerhome 推荐话题算法 中提及了此贴 19 Sep 17:58

我今晚看看

我们以前曾经尝试在项目中试点 cdc (消费者驱动的契约测试),技术用的是 spring cloud contract ,但后面发现用处不大。

主要原因是,实际项目中虽然微服务间通讯很多,但服务间基本都是通过使用 rpc 的方式来调用(例如 dubbo),schema 是以 java 代码(service定义接口,model定义具体数据内容)形式定义并把所有抽离成单独的 Jar 包供所有使用方以依赖项形式引入。双方都通过同样的 java 代码相互调用,基本不大会存在契约被破坏的情况。即使是一个 provider 多个 consumer ,由于用的 java 代码一致,也不存在契约字段数量、类型等对不上契约测试关注的问题点。

至于provider 或者 consumer 单方面调整协议导致另一方无法通讯,只要 provider 在修改时保证向下兼容即可(如 service 和 model 都只做增加),实在无法兼容的,通知对应所有契约使用方更新依赖 jar 包版本也可以解决。

当然,也有一个很大的原因时,我们微服务的总服务数量不多,在20个以内,provider 提供的契约最多也就给2-3个服务使用,且都是同一个团队或者沟通非常密切的团队。所以契约测试里提到的沟通不顺畅、同步不到位导致部分服务无辜被契约变更受累的问题也基本不怎么会出现。

陈恒捷 回复

你说的没错, dubbo的引用机制可以确保调用参数方法正确, 所以不要在java之间想这个事情, 想一下, 每个UI其实也是consumer, 每个h5都是consumer...是不是开朗些了

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up