契约测试？生产者？消费者？一文帮你理清楚

五星上将麦克阿瑟曾经说过“在契约测试面前，集成测试就是个弟弟“

契约测试

什么是契约？

如果从契约产生的阶段来说，现有资料表明最早要追溯到西周时期的《周恭王三年裘卫典田契》，将契约文字刻写在器皿上，就是为了使契文中规定的内容得到多方承认、信守，“万年永宝用”。所以订立契约的本身，就是为了要信守，就是对诚信关系的一种确立。诚信，是我国所固有的一种优良传统，也是延续了几千年的一种民族美德，在中国儒家的思想体系里，是伦理道德内容中的一部分。

然而，现在不是这么美好，现实中缺少契约精神的比比皆是

但是，在软件测试领域，契约这把利器，又重新的利用起来

先从测试金字塔讲起

对于测试而言，这个金字塔是理解测试级别的最好的隐喻，这个金字塔最早出于

Mike Cohn 在他的《Succeeding with Agile》，我们从底层往上读

1. 单元测试通常是添加到项目中最常见的测试。目标是在函数或方法级别验证代码。如果您有 sum 函数，那么您想要检查它5 + 5 = 10。通常编写和维护此类测试很容易。

/**
 * the function to test
 */

const sum = (a, b) => {
   
  return a + b;
};


/**
 * the unit test
 */

test("adds 5 + 5 to equal 10", () => {
   
  expect(sum(5, 5)).toBe(10);
});

2. 集成测试（或系统测试）检查组件之间的接口。您可以测试整个类或服务，这通常涉及mock模拟无法在测试环境中重现的外部接口。编写集成测试有点困难，因为涉及的代码更多，而且维护成本也更高。一次测试大量代码，因此追踪问题可能需要一些时间。
   
3. 端到端（E2E）测试是最完整的测试，因为目标是模拟产品的最终用户。您通常需要构建一个完整的端到端环境，其中包含应用程序的所有组件（所有服务、后端存储等）。您可以使用 Postman 等工具来模拟 REST 调用，或使用 Cypress 等工具来模拟通过 Web 应用程序界面的使用情况。通常，您将编写较少的 E2E 测试，因为它们在运行时间和维护时间方面都花费大量时间。

什么是锲约测试？

但是，显而易见的出现了一个问题

虽然金字塔顶部的测试更能代表客户的体验，

但它们也有一些令人痛苦的缺点。：

很慢；由于它们遍历多个系统并且通常必须串行运行，因此每个测试可能需要几秒钟到几分钟才能完成，特别是在必须执行先决设置（例如数据准备）的情况下。

难以维护；端到端测试要求所有系统在运行之前都处于正确的状态，包括正确的版本和数据。

可能不可靠或不稳定：由于编排测试环境的复杂性，它们经常会失败，导致误报，从而分散团队的注意力。在许多情况下，它们会由于与任何代码更改无关的配置问题而失败。

难以修复：当端到端测试失败时，由于问题的分布式和远程性质，调试问题通常很困难。

规模严重；随着越来越多的团队的代码得到测试，事情变得更加复杂，测试套件的运行速度呈指数级下降，并且发布在自动化管道中被堵塞。

在流程中发现错误为时已晚：由于运行此类测试套件的复杂性，在许多情况下，这些测试仅在代码提交后才在 CI 上运行 - 在许多情况下，由单独的测试团队在几天后运行。这种