为啥 “发请求” 本质上也是 Mock（仿制品？），不是个普通的接口测试吗？

不说炒不炒概念，加上 “发请求” 这部分后，能不把 “联调或提测的时候才发现后端修改了接口定义没有通知前端”，这种情况变成 “后端修改接口定义的代码一提交，前端就知道了” 这种情况呢

可以理解为一个基于 mock 技术和接口定义做的测试。mock 是一个技术，契约测试是一种测试类型。当然也有概念的成分啦，否则怎么和其它已有测试区分开

平时 mock 都是放在程序以外，单独维护，很容易出现代码更新后 mock 还没更新的情况。微服务下，这个问题会更加严重，因为十几个服务的 Mock 维护工作量可是不少的。并且调用链复杂的话，很容易上游改一个接口内容，下游就全都出问题。

契约测试则把 mock 放到应用中，更新代码同时更新这个 mock 。并且有用到这个服务的应用，都可以在单元测试中就直接启动这个基于最新接口内容的 mock 服务，不需要额外的服务器。自然也就起到了接口更新后如果不兼容，可以尽早发现的作用（前提是你要写针对服务调用的测试代码，哈哈）。这方面的详细内容，可以看看 spring cloud contract 的解决方案。

我们之前有尝试过，但因为项目中契约变动量不是特别大，而且说实话维护契约本身也是个不少的体力活，投入产出比并不高，所以后面放弃了。

这个图应该就能简单概括 pact 是啥了。
我们目前在实践的，参考https://docs.pact.io/
https://github.com/pact-foundation/pact_broker
澳洲的一家公司做的。

之前的一个项目改架构变成微服务，也引入了 mock 和 CDT，我的浅显理解是：

1. CDT 的目的很明确，是为了监督 provider 不要随便更改 API（参数以及类型），他也只验证 API 的定义而已。CDT 的 pact 由 consumer 提供，跑在 provider 端（我们的项目是在 CI/CD 里跑，如果不通过，provider 是不能 check in 的），那么如果 provider 要变更 API，必须和 consumer 协商，然后 consumer 更新 pact，然后 provide 才能提交更改。
2. 而微服务要单独测试，要测试跟别的服务的交互的话，mock 少不了。Mock 应该是由微服务测试人员进行，不管其是 provider 还是 consumer，只要需要测到跟其他微服务的集成，就需要进行 mock，目的是为了测试自己的微服务的各项功能的。

这个问题太常见了，流程不规范，经常会有这个问题

这块我们是打算做一个配置化的 Mock 平台来处理，而每个请求的相应会根据字段规则的不同来路由返回的结果，这样能够可视化配置，减少维护的成本，而且没有对代码做了侵入性的修改，不过一切都还在理论阶段，所以专门开一个帖子来了解一下，你这么说我大概有了一些概念了。

恩，网上太多都是把 pact 的 demo 贴出来，估计自己都不懂这个是要做啥的，刷刷流量而已，所以才会有这个疑问，谢谢你贴的地址，我去看看。

谢谢！所以这块的核心，还是一个 provider 和 consumer 的监督，相当于在传统的 Mock 基础上增加了监督接口的功能。

那下一个问题就是，你是相信行政规定在 Word 里的流程，还是相信嵌在代码里被机器执行的流程

mock 是单向的，客户端消费。契约是双向的，服务端～客户端的双向约定。