如果您在互联网上搜索“意外的 API 行为”，您很快就会发现没有人喜欢 API 未按预期工作的情况。当您考虑到 API 的数量不断增加、持续开发以及构建在其之上的服务的交付时，API 可能偏离其预期行为也就不足为奇了。这就是为什么 API 测试覆盖率对于成功至关重要。多年来，我们为 API 创建了单元测试和功能测试，但接下来我们该何去何从呢？
单一事实来源
要理解契约测试，您必须首先理解单一事实来源 (SSOT) 的概念如何融入 API 开发。维基百科将其描述为“构建信息模型和关联数据模式的实践，使得每个数据元素只存储一次。” 这是一种用词繁琐的方式，意思是 SSOT 是每个人都同意的东西，您不必重复自己。它可能是后端和前端工程团队之间、维护人员之间，或者可能是软件架构师及其团队之间的协议。
由于开发发生在许多不同的团队、时区和媒介中，因此拥有可以参考的 SSOT 会很有帮助。在 API 开发中，这就是 OpenAPI 规范派上用场的地方。
什么是 OpenAPI 规范？
OpenAPI 规范（以前称为 Swagger）是一种供应商中立、可移植且开放的 API 描述格式，它标准化了 REST API 的描述方式。还有其他可用的格式（例如，API Blueprint 和 RAML），但是，随着 OpenAPI Initiative 的创建，所有证据都表明 OpenAPI 是目前最流行的 API 规范格式。
我将 OpenAPI 规范 (OAS) 视为帮助我们沟通 API 的桥梁。由于 API 是人类和机器的混合体，因此 OAS 是这些机器和其他人类之间的桥梁，一种通用语言。与任何标准一样，它使用集中化的语言来描述事物。OpenAPI 对特定属性的描述是为了让机器可以处理它们（例如，测试）。
为您的 API 拥有 OAS 还允许您
- 生成 API 参考文档
- 拥有开发契约
- 设置模拟服务器并原型化您的 API
- 基于规范创建服务器存根或库
契约测试
OAS 就像一个契约，因为它是一个需要遵守的协议，但是您如何测试契约呢？许多 API 测试（例如，单元测试）只是检查以确保特定端点给出良好的 200 响应代码，这很重要，但是当 API 更改时会发生什么？您是否在检查以确保您没有破坏依赖于它的其他服务？
契约测试是编写测试，以确保 API 或微服务符合您的契约中描述的标准和定义。在契约测试中，您不必为不同的属性编写数十个甚至数百个断言，因为您已经有了契约——您的 OAS。它对于测试服务器代码、SDK、客户端库甚至第三方 API 中 API 实现的准确性非常有用，当其他服务依赖于 API 时，这一点尤其有用。这可以带来更快的开发、更少的破坏性代码更改以及更准确的实现。
要对您的 API 进行契约测试，您需要一个服务器作为您正在测试的传入请求的验证层。Prism 服务器就是其中一个例子。它是一个高性能、无依赖的服务器，专门构建用于在 OAS 之上处理 Web API。它可以验证您的传入 API 请求，以确保它们与规范中的契约匹配。
契约测试的一个例子是 JSON 模式验证。您将测试整个嵌套的响应正文，以确保每个字段都与 API 设计的规范匹配。这将确保您的 API 实现不会破坏依赖于它的其他服务。
重要的是要注意，契约测试并不是一个新概念。它在 2000 年代初期开始受到更多关注，并且有几个不同的名称，例如抽象测试用例。随着 API 和微服务的演进，它正逐渐成为与传统方法并行的更常见的测试策略。
损坏的库
让我们让这更贴近现实生活。假设您有一个 API，其中包含几个不同的客户端库（有时称为 SDK）。有人为其中一个库做贡献，处理一个功能问题，该问题添加了功能以匹配新的 API 操作。此功能是维护人员非常需要的，并且它获得了快速的拉取请求审查并合并到库中。
一周后，有人报告了库中的错误。他们没有获得与 API 参考文档中针对该操作应存在的相同 JSON 数据结构。另一位维护人员想知道，发生了什么事？API 更改了吗？参考文档是否正确？库内部发生了什么事？库用户是否正确使用它？
在咨询了 API 实现、文档、错误报告者和库实现后，我们发现合并的库实现是不正确的。它为 API 操作的响应使用了相似但不正确的 JSON 数据结构。这种情况本可以如何避免？契约测试！
您可以对 API 库进行契约测试的一种方法是在拉取请求审查过程中包含它。它可以自动化在您的持续集成 (CI) 工具中，或由审查者手动运行，这本可以在所描述的示例中完成。与规范不一致的库更改永远不会通过契约测试，从而确保您的客户端库始终准确。
Taylor Barnett 将在 7 月 16 日至 19 日在俄勒冈州波特兰举行的第 20 届年度 OSCON 大会上介绍 使用 OpenAPI 规范更好地进行 API 测试。
1 条评论