Kong Insomnia CLI 和 GitHub Actions 的 API 的# CI
Insomnia 是来自Kong的桌面应用程序,非常适合构建、调试和测试后端 API。虽然临时手动测试很好,但将我们的 API 测试包含在我们的持续集成 (CI) 管道中不是更好吗?使用 Inso,Kong Insomnia 的 CLI 工具,我们可以!
Inso 允许您直接从命令行运行自动化 API 测试,这意味着使用 GitHub Actions 设置工作流程非常简单。
在本文中,我们将使用 Node.js 和Express创建一个简单的服务器,使用Kong Insomnia编写 API 测试,然后使用Inso和[GitHub Actions]在我们的 CI 管道中运行这些测试(https://resources.github.com/devops/tools/automation/actions)。
演示应用程序:任天堂游戏数据库
我们已经建立了一个游戏数据库,其中包含有关曾经发布的每款NES游戏的信息。该应用程序是一个服务器,它实现了一个带有端点的 REST API,以获取有关游戏、类别、开发人员、发行商和发布年份的数据。
你可以在 GitHub上找到完整的代码。
使用 Kong Insomnia 进行手动测试
在开发 API 时,快速的反馈周期有助于确保您的 API 以您想要的方式工作并返回您期望的数据。 Kong Insomnia 非常适合这种临时测试。
为了开始使用我们的 NES 游戏 API,我们在 Kong Insomnia 中创建了一个新的设计文档。我们将“设计”选项卡中的信息留空,然后前往“调试”选项卡开始发出请求。下面,我们对服务器提供的每个 API 端点都有请求。我们可以在 Kong Insomnia 中运行每个请求,并将结果数据显示在 UI 中。
[
中的示例 API 请求](https://res.cloudinary.com/practicaldev/image/fetch/s--2s9rAF0t--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev -to-uploads.s3.amazonaws.com/uploads/articles/5l4g9yoioswm9401t5l0.png)
Insomnia 中的示例 API 请求
Kong Insomnia 写作测试
手动访问我们的 API 端点非常适合临时测试和调试,但最终我们想要的是一个自动化测试套件,以确保我们的应用程序行为正确。Kong Insomnia 允许您在桌面应用程序的“测试”选项卡中编写测试。
通过从“调试”选项卡中选择一个请求,然后对服务器返回的数据进行断言来编写测试。您可以运行单个测试或一整套测试。
正如您在下面看到的,我们为每个 API 端点编写了测试,在我们的测试套件中总共进行了 11 个测试。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--Wg9elu6F--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev- to-uploads.s3.amazonaws.com/uploads/articles/m6ijo4qkm8nxourrzsi1.png)
Insomnia 中的 API 测试
这些测试(以及我们设计文档中的信息)可以与 Git 同步并包含在我们的代码仓库中。这样,任何拥有 Kong Insomnia 桌面应用程序的人都可以运行这些请求和测试。
要将 Kong Insomnia 与 Git同步,只需单击应用程序顶部的“设置 Git 同步”按钮。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--NFHyxoSy--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// dev-to-uploads.s3.amazonaws.com/uploads/articles/xisvr8oit6md60kvftza.png)
在 Insomnia 中设置 Git Sync 按钮
从那里,您可以提供相关详细信息以将 Kong Insomnia 与您项目的 Git 存储库连接起来。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--qONBu2o0--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// dev-to-uploads.s3.amazonaws.com/uploads/articles/zzx2u3gne0i39i2i3z3i.png)
将 Insomnia 与您的 GitHub 存储库链接
将 Kong Insomnia 与您的 Git 存储库同步需要身份验证令牌。您可以在 GitHub 的帐户设置中轻松创建个人访问令牌。
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--VnXp1Ftd--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// /dev-to-uploads.s3.amazonaws.com/uploads/articles/ulbgxo3cy509xr35qvtv.png)
在 GitHub 中创建个人访问令牌
使用 Inso 从命令行运行测试
现在,我们在 Kong Insomnia 中有一组请求和一组测试,可以帮助我们进行调试和测试。但是我们还没有自动化这些测试的运行,所以现在让我们这样做。这就是 Kong Insomnia 的 CLI Inso 发挥作用的地方。
Inso 可以作为 npm 包安装,因此我们将其作为开发依赖项添加到我们的项目中:yarn add --dev insomnia-inso。
为了简化测试套件的运行,我们在package.json文件中创建了一个 npm 脚本。以下脚本使用 Inso:"test": "inso run test \"NES Games API Test Suite\""运行我们的测试。这意味着我们可以简单地运行yarn test以随时从命令行运行我们的测试。
将 Inso 与 GitHub Actions 集成
现在是我们迄今为止设置的所有内容的高潮:将我们的自动化测试作为持续集成管道的一部分运行。很高兴我们可以从命令行运行我们的测试,但是现在,我们没有让它们在任何地方自动运行。我们真的希望我们的测试套件能够在每个新的拉取请求上运行。这样做将确保在将任何新代码合并到主分支之前测试通过。这是最好的持续集成。
GitHub Actions允许我们使用 YAML 文件配置我们想要的任何持续集成。我们在其中创建了一个.github/workflows目录和一个unit-tests.yml文件。该文件全文转载如下:
name: NES Games API CI
on:
push:
branches:
- master
pull_request:
branches:
- master
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout branch
uses: actions/checkout@v2
- name: Use Node.js 14.x
uses: actions/setup-node@v2
with:
node-version: 14.x
cache: 'yarn'
- name: Install dependencies
run: yarn install --frozen-lockfile
- name: Start server and run unit tests
run: yarn ci:start-and-test
进入全屏模式 退出全屏模式
如您所见,我们的工作流程检查了我们当前的分支,使用 Node v14,使用 yarn 安装我们的依赖项,然后运行自定义脚本来启动我们的应用程序的服务器并运行 API 测试。每当将代码推送到主分支或针对主分支打开新的拉取请求时,都会触发此工作流。
这个ci:start-and-test脚本是我们添加到package.json文件中的另一个 npm 脚本。使用 npm 包wait-on和同时使用,我们使用这个脚本来启动我们的服务器,运行 API 测试,然后在测试完成后终止服务器。我们的package.json文件中的 npm 脚本的完整列表复制如下:
"scripts": {
"ci:start-and-test": "concurrently -k -s=first \"yarn start\" \"yarn ci:test\"",
"ci:test": "wait-on http://localhost:3000 && yarn test",
"format": "prettier --write .",
"format-watch": "onchange . -- prettier --write {{changed}}",
"start": "node index.js",
"test": "inso run test \"NES Games API Test Suite\""
},
进入全屏模式 退出全屏模式
现在,我们有一个漂亮的工作 CI 管道!
我们可以通过在我们的仓库中创建一个小的拉取请求来测试一切是否正常工作。发出拉取请求后,我们可以看到我们的 CI 管道正在运行:
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--zuoyzZYq--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/ https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ukvjwbnizb5thhmgn2j.png)
CI 管道正在为我们在 GitHub 中的拉取请求运行
如果我们单击详细信息按钮以查看更多信息,我们可以看到正在运行的工作流的各个步骤:
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--TLT-JJca--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev -to-uploads.s3.amazonaws.com/uploads/articles/ibn3hyay32b8ndewlwbw.png)
CI 管道步骤
一旦作业通过,结果将报告回拉取请求,如下所示:
[
](https://res.cloudinary.com/practicaldev/image/fetch/s--flOyVbDb--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https: //dev-to-uploads.s3.amazonaws.com/uploads/articles/1kxmwivmrmy9ql0yb6zu.png)
CI 管道已通过我们的拉取请求
我们做到了!所有检查均已通过。
为了完整性,我们可以做的最后一件事是要求所有检查在 GitHub 中通过,然后才能合并拉取请求。我们可以在 GitHub 中的 repo 设置中执行此操作:
[
合并拉取请求之前需要通过状态检查 ](https://res.cloudinary.com/practicaldev/image/fetch/s--PNH9eYBG--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880 /https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2se30tcuzznjytlrawjf.png)
在 GitHub 中合并拉取请求之前需要通过状态检查
如果你想探索另一个潜在的 CI 设置,Kong 团队也有他们自己的示例工作流你可以使用它来安装 Inso 作为 CI 管道中作业的一部分,他们的setup-inso GitHub Action。
结论
那么,我们今天完成了什么?很多,其实!我们已经使用 Node.js 和 Express 创建了一个服务器。我们在 Kong Insomnia 中创建了临时请求,以帮助开发和调试我们的 API。我们已经在 Kong Insomnia 中编写了测试,并学会了使用 Inso 从命令行运行它们。最后,我们使用 GitHub Actions 创建了一个 CI 管道,以运行我们的 API 测试,作为我们存储库的每个拉取请求的一部分。
Kong Insomnia、Inso 和 GitHub Actions 携手合作,帮助我们自信地开发应用程序。我们的持续集成管道让我们可以随时部署我们的应用程序。成功!
更进一步,我们可以将此工作流程合并到一个更广泛的策略中,以管理整个 API 开发生命周期——在 Kong Insomnia 中进行设计和开发,使用 Inso 与我们的 CI 管道集成进行部署,以及使用Kong Gateway等工具进行管理和维护.
感谢阅读,祝您编码愉快!
更多推荐

所有评论(0)