u8api openapi_使用OpenAPI规范进行更好的API测试

u8api openapi

如果在Internet上搜索“意外的API行为”，您会很快发现，没有人喜欢API无法正常工作。 当您考虑API的数量不断增加，持续开发以及在其之上构建的服务的交付时，API可以偏离其预期行为也就不足为奇了。 这就是API测试覆盖率对成功至关重要的原因。 多年以来，我们已经为API创建了单元和功能测试，但是从那里去哪里呢？

真理的单一来源

Wikipedia将其描述为“构造信息模型和关联的数据模式的实践，这样每个数据元素仅存储一次。 这是一个word琐的说法，SSOT是每个人都同意的事情，您不必重复自己。 这可能是后端和前端工程团队之间，维护人员之间，或者软件架构师与其团队之间的协议。

由于开发发生在许多不同的团队，时区和媒介中，因此寻找SSOT有帮助。 在API开发中，这是OpenAPI规范变得很方便的地方。

什么是OpenAPI规范？

OpenAPI规范 （以前称为Swagger）是一种与供应商无关的 ，可移植的，开放的API描述格式，用于标准化REST API的描述方式。 还有其他可用格式（例如，API蓝图和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年代初开始受到更多关注，并以一些不同的名称出现，例如Abstract Test Cases。 随着API和微服务的发展，它已成为与传统方法一起越来越普遍的测试策略。

破损的图书馆

让我们将其变得更加真实。 假设您有一个包含几个不同客户端库的API（有时称为SDK）。 为这些库之一做出贡献的人正在解决一个功能问题，该功能增加了功能以匹配新的API操作。 维护人员非常需要此功能，并且可以快速进行拉取请求审查并合并到库中。

一周后，有人报告库中的错误。 他们没有获得与API参考文档所说的操作相同的JSON数据结构。 另一个维护者想知道，发生了什么事？ API是否更改？ 参考文档是否正确？ 图书馆内部发生了什么事吗？ 库用户是否正确使用它？

在咨询了API实现，文档，错误报告程序和库实现之后，我们发现合并的库实现是不正确的。 它对API操作的响应使用了类似但不正确的JSON数据结构。 如何防止这种情况发生？ 合同测试！

可以对API库进行合约测试的一种方法是将其包含在请求请求审核过程中。 它可以在您的持续集成（CI）工具中自动执行，也可以由审阅者手动运行，这可以在上述示例中完成。 对与规范不符的库进行更改将永远不会通过合同测试，从而始终确保客户端库的准确性。

---

泰勒·巴内特（Taylor Barnett）将于7月16日至19日在俄勒冈州波特兰市举行的第20届OSCON上展示采用OpenAPI规范进行的更好的API测试 。

翻译自: https://opensource.com/article/18/6/better-api-testing-openapi-specification

u8api openapi