本文探讨了契约测试的概念，起源于古老的诚信契约，但在软件测试领域中重新焕发活力。契约测试旨在解决集成测试的效率和稳定性问题，通过解耦服务依赖和创建契约来提高测试速度。文章介绍了契约测试的两种模式——Provider-Driven Contract和Consumer-Driven Contract，并讨论了它们的适用场景。此外，还分析了契约测试与持续交付(CD)的整合，以及契约测试的优缺点和维护问题。契约测试不是端到端测试或单元测试的替代品，而是作为服务间API测试的有效工具。
什么是契约
如果从契约产生的阶段来说，现有资料表明最早要追溯到西周时期的《周恭王三年裘卫典田契》，将契约文字刻写在器皿上，就是为了使契文中规定的内容得到多方承认、信守，“万年永宝用”。所以订立契约的本身，就是为了要信守，就是对诚信关系的一种确立。诚信，是我国所固有的一种优良传统，也是延续了几千年的一种民族美德，在中国儒家的思想体系里，是伦理道德内容中的一部分。
《现藏于台北故宫博物院》
现实真的是那么美好吗？小时候的价值观教育未能改变社会的现状，缺少契约精神的案例却比比皆是。
那么，契约真的要消失了吗？不尽然，在软件测试领域，我们又重新拾起了契约这把利器。
发展历程
接下来让我们把时间回溯到2011年初，回到老马的文章《集成契约测试》中来，回顾一下契约测试的起源和发展历程：
假设我们有这样一个场景：A团队负责开发API服务，B团队进行API调用消费服务。
为了保证API的正确性，我们会对外部系统的API进行测试（除非你100%相信外部系统永远正确和保持不变），这很可能就会导致一个问题，当外部系统并不那么稳定或者请求时间过长时，就会导致我们的测试效率很低，并且稳定性下降。比如当外部API挂掉导致测试失败时，你并不能完全确信是API功能被更而改导致的失败还是运行环境不稳定导致的请求失败。
最初，解决这个问题的方案是构建测试替身（[Test Double](https://martinfowler.com/bliki/TestDouble.html
)），通过模拟外部API的响应行为来增强测试的稳定性和反应速度。实现手段是在测试环境中搭建一个模拟服务环境，通过设定一些请求参数来返回不同的响应内容，然后再被内部系统调用，来保证调用端的正确性。构建模拟环境时我们可以使用几种不同的测试手段，如Dummy，Fake，Stubs，Spies，Mocks等。可是，问题又来了，如果使用测试替身那如何能保证外部系统API变化时得到及时的响应，换句话说，当内部系统测试都通过的通过时，如何能保证真正的外部API没有变化？
最低0.47元/天 解锁文章
扫一扫
894
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
