是的
既然如此，它的意义在哪里呢？我就是带着这样的疑问进了现在的项目组 - API， Application Programming Interface

在解释这个回答之前，让我们先来回顾两个测试问题：

为什么单元测试需要Mock？

mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法

如果容易构造且获取，那就可以不用Mock而直接用于测试中了。而且单元测试的目的是为了测试自己的函数功能，

为什么需要集成测试？

集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

文中指的就是将两个模块组装成子系统的简单集成测试。

仔细想一下，如果是单元测试Mock+集成测试好像就可以解决很多外部服务依赖问题了，但这里有个问题，Provider如何知道自己的实现满足了Consumer的需求呢？

契约测试

在Martin Fowler的ContractTest中，了解到契约测试要解决的痛点是 - 减少双方约定的契约（API文档）有非预期的破坏

在Pact的实践中，相当于有两个Mock Service，一个是Mock Provider，另一个是Mocker Consumer。

Pact Interaction.png

当Consumer端写测试时，用的是Mock Provider，这跟通常意义下的Mock Server是一个意思，即针对固定请求，返回使用的最小Response，也就是说，你不关心的字段可以不用测试，只返回自己需要的内容，同时生成契约并放到公有的地方，这里Pact用到的是Broker。

Provider Verification.png

接着，Provider端会将契约从公有地Broker上拿下来，由Mock Consumer将契约中的请求发给真正的Provider，并验证真正的返回结果和契约中预期的返回结果是否匹配，并将结果回传至broker。可能只有类型、格式和数量的校验，但也足够了，其他的细节测试可以有Provider的功能测试来覆盖。

Broker中会收集Consumer端share过来的契约，也是一个展示Verify结果的地方。

Pact Broker.png

其中Latest pact published是Consumer最近的一次发布的时间，Last Verified是Provider端最近的一次verification的时间

当broker中verify的结果有失败时，Consumer和Provider双方都需要警觉了，肯定是契约被某一方破坏了，或者Consumer的需求变了，或者是实现变了，或者是人为的错误，但Pact的目的是发现问题并达成一致，从而继续推进。

理想情况下，如果Consumer需求有变动就先去找Provider商量，或者Provider端有升级前找各Consumer协商，就不会发生问题了，测试的核心是以防万一，在万一发生的情况下，如何快速知道已经出错，并快速制定解决方法而不至于导致更坏的结果。

在解释了单元测试、集成测试和契约测试之后，我们来看看不同，

	单元测试	（简单的）集成测试	契约测试
目标	构造数据，测试自己某个模块的功能是否正常	调用外部服务API，测试是否能正常连接	双方校验，任何一方发生变动，既契约的被破坏，都会警觉
范围	单元测试是模块的自测，可以写在任何地方，不管是Consumer还是Provider，不管是前端还是后端	集成测测试是测试下游服务能否调通，无论Cosumer还是Provider都有下游服务，都可以有集成测试，测试的是不同的东西	发生在服务和服务之间，但测试和维护的都是同一个东西，且有反馈

场景1

团队在做API，供整个企业之后使用，他们需要构建监控，日志，登录，购买商品，支付等服务。

其中，如果监控和日志这些是用微服务自己做，那就可以使用契约测试，其他服务会消费它
如果登录，支付这些集成第三方的成熟的身份认证系统，或支付系统，就可以使用集成测试。

场景2

团队在做API，供整个企业之后使用，他们需要构建监控，日志，登录，购买商品，支付等服务。

同样的场景，如果所有的服务都是自己来构建，那就可以使用契约测试将所有的服务都管理起来。

场景3

大厂提供API供很多企业使用。通常会比较稳定，鲜少会改变。

如果想引入契约测试，Consumer端需要提供契约，Provider端需要构建Broker和进行验证测试。

误区一
契约测试的理想国是Provider端不需要写测试，所有Consumer的用例总和构成了Provider端测试的全部集合。这句话的弊端就在于provider端太寄希望于Consumer了，这就相当于让测试相信开发一样，不是说开发不可信，是以防万一。

误区二
曾经觉得，可以将契约测试中的Consumer测试结合到一起，既替换单元测试中的Mock。却忽略了单元测试在测试金字塔中是属于最底层的，代价小，效率高，所以case覆盖会很多，如果与契约测试结合到一起，会造成冗余及滥用。

写在最后

回到最初的问题，确实契约测试的验证会比较简单，但它的优势就是监督双方或多方，在问题发生时，触发沟通或交流来达成一致，从而避免真正的问题发生，它的出现不是为了取代谁，而是关注点的不同 - 关注契约关注双方。