用契约测试解耦功能测试

随着微服务的发展，一个功能的验证往往依赖十几二十个服务的 ready。在日常的项目过程中，往往会出现服务之间的上下游依赖，导致整体功能测试的进度依赖于最长路径的现象。

通过接口契约解耦上下游的依赖，是目前比较流行的做法。于是，接口契约的验证，就成了功能测试解耦的关键卡点。

首先，我们可以将契约测试分成服务验收和客户端集成逻辑验证两部分。

对于服务验收，比较简单，只需要 mock 入口报文、调用服务、验证出口报文，验证内部数据状态就可以了。不管提供的服务是 one-way 还是 request-response 的，都一样处理。

对于客户端的集成逻辑验证，依赖于服务端的 ready，这里我们分三种情况分别处理：

1. 服务是 one-way 的，也就是客户端给服务端一个通知，完全不依赖通知的结果。这种情况比较简单，只需要验证给到服务端的通知是否符合契约的要求就可以了。

2. 服务是通过异步实现的。也就是 request 和 response 的交互是通过异步消息完成的。这种情况下，可以用两段的方式进行验证。第一段是 request 的 one-way，验证报文是否符合接口契约。第二段 response 通过 mock 的方式生成，触发客户端的后续逻辑。

3. 同步的 request-response。这种情况就比较复杂。需要引入额外的组件完成串联。通用的思路是：对于 integration 进行切面拦截，在切面中 mock 服务端，完成对于 request 的验证，根据 request 条件生成 response 报文，同时完成 response 的返回。pact（https://docs.pact.io/）是完成这个能力比较好的框架，但是目前只支持 restful 的方式。但是我们可以通过增加各类 RPC 框架切面的方式，很好的进行扩展。

通过契约测试，我们可以将上下游串行的测试变为基于契约的并行化的测试方式。各个应用完成对自身提供的服务（port）和依赖的服务（integration）的契约测试，完成自身内部的质量保证。后续的端到端系统测试和 UAT 就不会因为上下游集成的问题导致 fail 或者延迟。