Contract Testing 的优点
契约测试与测试金字塔
谈论契约测试之前，我们可以先思考一下，在传统的自动化测试方法中，契约测试大概处于什么位置和角色。说起自动化测试，最有用的经验法则就是 Mike Cohn 提出的测试金字塔。我在先前一篇什么是敏捷测试金字塔的文章中简单介绍过敏捷测试金字塔的结构，有兴趣的朋友可以去看看。
Mike Cohn 在介绍敏捷测试金字塔的书中，提到：
如果遵守测试金字塔的结构来编写测试用例，那么你就可以获得一个健壮的、高效的、可维护的测试用例集合，它包含：许多小巧高效的单元测试用例、一些粗粒度稍大的中间层的业务型测试用例或集成测试用例、以及非常少的上层的 UI 测试用例。
我先前在初识Contract Testing一文中介绍过，契约测试是为了解决传统集成测试中的缺点而诞生的，所以它是集成测试的补充，因此，在金字塔结构中，契约测试处于中间的Service Tests这一层，它们和集成测试有同样的目标。它们的目的是给你足够的 confidence，证明你需要集成的系统，能够和你开发的组件、微服务等很好地兼容。（注：金字塔上的 “UI Tests" 有时和集成端到端测试 ”Integrated e2e Tests“ 是一个意思）。
集成端到端测试的问题
金字塔顶端的集成端到端测试能更形象地表达用户可能会经历的使用体验，然而，这种集成端到端测试有许多弊端：
- 它们执行起来低效而缓慢：因为它们需要遍历多个系统而且依次地执行，而且有时候还需要一些预先环境准备；
- 难以维护：端到端的测试要求在执行前系统处于正确状态，包括正确的代码版本和正确的数据；
- 可能不够可靠或者行为古怪：由于测试环境的复杂性，这类测试通常会导致假阳性（误报），从而误导开发团队，有时测试没通过只是由于配置的相关错误，而不是代码的错误；
- 难以修复 bug：端到端测试报错后，通常很难调试，因为这类测试对象通常分布在不同的机器上或远程环境中；
- 规模劣势：当越来越多团队的代码或系统包括在端到端测试中，测试的成本将成指数级上升，而测试速度将呈指数级下降，这导致在整个自动化 pipeline 流程中，版本的发布将显著拥堵而延迟；
- 较晚发现问题：由于端到端测试所需环境比较复杂，所以往往放在产品开发流程的后期才实施，导致这个环节发现问题已经很晚，在现代敏捷开发模式中，这将带来高昂的成本。
由于存在这些问题，所以通常建议在集成端到端测试环节，只包含 cover 核心业务的、尽可能少的测试用例。
契约测试的价值
集成端到端测试的这么多缺点，到了契约测试，反而成了优点：
- 契约测试通常运行起来很快，因为不需要和多个相关的系统对话；
- 便于维护：契约测试的核心是契约，契约也可以像代码一样有版本管理；
- 容易调试和修复 bug：因为 bug 出现在你测试的单个系统上，所以通常很容易定位；
- 可重复运行；
- 规模优势：由于每个系统/组件独立地测试，所以自动化构建的 pipeline 不会带来指数级增长的成本；
从业务角度来说，我们都知道在产品周期越晚发现 bug，修复的成本越高：
通过把自动化测试过程中的大部分 effort 用于快速的单元测试和本地集成测试，你可以让整个产品的构建流水线变得高效。
其它好处
契约测试还有其它好处：
- 能够在开发服务端 API （比如 React Web App）之前，先开发并测试消费者（客户端）；
- 能够把生产者（服务端）的需求拉出来单独开发，这意味着你只需关心和实现服务端这边的功能；
- 测试用例的文档（契约）非常清晰易懂，比如：Given … a request for … will return …，一看就能明白服务器的行为；
- 通过契约文档还能知道客户端关心哪些请求字段；
参考
https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid
「 您的赞赏是激励我创作和分享的最大动力! 」
- 原文链接：https://zhuyinjun.me/2022/benefits_of_contract_testing/
- 版权声明：本创作采用 CC BY-NC 4.0 国际许可协议，非商业性使用可以转载，但请注明出处（作者、链接），商业性使用请联系作者获得授权。