契约测试
契约测试的思想就是将原本的 Consumer 与 Provider 间同步的集成测试，通过契约进行解耦，变成 Consumer 与 Provider 端两个各自独立的、异步的单元测试。
契约测试的优点：
契约测试与单元测试以及其它测试之间没有重复，它是单纯验证Provider与Consumer之间按预期的方式交互，定位准确；不需要部署真实的系统环境、Mock机制、没有真实API调用，运行非常快、反馈及时、修复周期短、成本低，在这种情况下，自动化测试流水线运行更快了，产品流水线出产品安装包也更快。因此，显然契约测试才是真正对的选择。
契约测试的缺点：
- 契约测试无法做安全或性能测试等。
- 契约测试采用Mock机制，所以没有集成测试更接近真实环境，也不能给业务人员做验收，可视性差。
- 契约测试基于不同的服务使用的协议不同，验证契约的复杂度会不同，复杂度过高时，需要权衡是否有必要加契约测试。
别再加端到端集成测试了，快换契约测试吧 - 简书 (jianshu.com)
基于Consumer驱动的契约测试分两个阶段：
- Consumer生成契约，开发者在Consumer端写测试时Mock掉Provider，运行测试生成契约文件；
- Provider验证契约，开发者拿契约文件直接在Provider端运行测试进行验证。
Pact和Spring Cloud Contracts是目前最常用的契约测试框架， Pact 实现就采用 Consumer-driven Contract Testing
Pact
Overview | Pact Docs
Pact 是事实上的 API 合约测试工具。用快速、可靠且易于调试的单元测试取代昂贵且脆弱的端到端集成测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
