解读微服务下的契约测试——看微服务如何完整应用系统验证之道 _微服务

契约测试

◎ 契约测试概述
◎ 契约测试与TDD
◎ 契约测试与独立交付
◎ 契约测试的相关技术与用法实战

在微服务架构中最常见的事情就是远程调用，如服务和服务之间的远程调用，前端和后端之间的远程调用，BFF和服务之间的远程调用，等等。当一个服务的接口发生变化时，依赖它的消费者也需要进行相应的调试或修改，如果这个过程采用口口相传或文件通知的办法，就会很低效，而且容易遗漏。在大多数时候服务端并不能清楚地知道全部的消费者有哪些，哪个接口会影响哪个消费者。这时就需要一种自动的方法来帮助我们测试接口的可靠性，这就是契约测试。
契约测试概述契约也就是合约，是双方当事人意见一致并且要共同遵守的行为表示，服务的调用者和提供者就好比签订契约的甲方和乙方。契约测试就是验证签订契约双方的行为是否符合契约。
通常我们并不知道服务间的依赖关系是怎样的，如每个接口的消费者是谁，相同的接口不同的消费者都需要哪些数据，这些消费者正在消费哪个版本的接口等，要在一个项目中理清这些问题显然有些困难，哪怕管理做得再好，也不可能面面俱到，而且文件记录和实际情况往往会有差距。

文章插图

如何能准确地检测接口的变化所带来的影响？是否管理所有服务端与消费者之间的关系？虽然这样做看似可行且最直接，但是要管理所有接口的版本、调用关系等信息无疑是一个巨大的工程，而且也只能完成快速定位接口，并不能完全保证把影响降低，解决这些影响。一旦有遗漏，就意味着系统有问题。
契约测试的做法能解决上述问题，在微服务中，无论是服务与服务之间，还是服务与前端之间，抑或是服务与API Gateway之间，只要双方有远程调用的依赖关系，都可以定义一个关于双方所依赖的接口契约，约定好接口的请求和返回信息，包括地址、参数、头部、响应数据等，并且最好通过Git等版本管理工具将契约管理起来。

文章插图

由服务提供者和调用者共同维护，双方需要严格遵守这份契约，通常我们会将这份文件的信息解析出来，作为双方单元测试的基准，然后消费者和服务者双方都会测试自己的服务或请求是否遵守这份契约的规则，从而保证双方依赖接口的正常使用，契约测试示意如图4.1所示。

文章插图

只要一方发生变化，就会导致测试的失败，然后变化的一方就会去更改契约并且通知相关接口调用者。假设忘记通知其中一个调用者，这个调用者在使用最新的契约进行测试时，也会测试失败，然后就会发现这个接口的变化，最后沟通并修复问题，这就是契约测试。
这样做的好处是，当服务端接口变动后，只需修改对应的契约文件，就能让契约的另一方测试失败，准确地分析接口的影响范围，并且如果契约测试是自动化的，整个过程成本极低，而且高效、准确，这样我们就能通过自动化测试的手段，最大限度地避免人为的遗漏，保证服务提供者和调用者之间依赖的正确性。
而消费者如果想对接口进行调整，同样可以修改契约文件，然后服务端的契约测试就会失败，保证服务提供者对于接口的验证。
这份契约不仅可以作为服务端和客户端的逻辑验证，还可以用来模拟一个后端的服务，接口的调用者就不用等到服务开发完成后才能调试程序，服务提供者和调用者双方通常会在最开始定义好接口的契约，然后服务提供者依据契约去开发接口，服务调用者则可以使用契约模拟一个假的服务实例，通常称这个假的服务实例为Mock Server 。调用者会先用Mock Server来开发自己的程序，等真实的服务开发好后再进行集成测试，这种做法在前后端分离开发中尤为常见，如图4.2所示。

文章插图

契约测试与TDD测试方式有很多种，如单元测试、集成测试、E2E测试、冒烟测试等，对于开发人员来讲,接触最多的是单元测试。契约测试也是单元测试的一种，说起单元测试就需要提到TDD，接下来了解一下契约测试在TDD中的实践。
TDD的定义TDD（Test-Driven Development，测试驱动开发）是一种软件开发过程中的应用方法，提倡在编写代码时先写出测试，然后编码实现，编码的目的就是让测试通过，以达到一种由测试驱动开发的过程，并因此得名TDD 。