使用 Prisma 进行测试的终极指南：CI 流水线

目录

• 目录
• 引言
  • 什么是持续集成流水线？
  • 您将使用的技术
• 前提条件
  • 假定知识
  • 开发环境
  • 克隆仓库
• 设置您自己的 GitHub 仓库
• 设置工作流
• 添加单元测试作业
• 添加集成测试作业
• 添加端到端测试作业
• 总结与最终思考

引言

在本系列文章即将结束之际，请后退一步，回顾一下您在过去四篇文章中取得了哪些成就。您已经：

1. 模拟了 Prisma Client
2. 学习并编写了单元测试
3. 学习并编写了集成测试
4. 学习并编写了端到端测试

您所学的测试策略和概念将使您能够编写代码，并验证新更改是否在现有代码库中如您所愿和期望地工作。

这种安心感非常重要，尤其是在大型团队中。然而，您所学的内容中有一个不足之处：需要在进行更改时手动运行测试。

在本文中，您将学习如何自动化测试的运行，以便在向主分支创建拉取请求时自动测试代码库的更改。

什么是持续集成流水线？

持续集成流水线描述了一系列在发布新版本软件之前必须完成的步骤。您可能见过或听说过 CI/CD 这个缩写，它指的是持续集成和持续部署。通常，这些独立的概念是通过像您今天将要查看的流水线来处理的。

在本文中，您将主要关注CI部分，您将在其中构建、测试并最终合并您的代码。

有许多技术允许您设置流水线，选择哪种通常取决于您使用的技术栈。例如，您可以在以下平台设置流水线：

• Jenkins
• CircleCI
• GitLab
• AWS Codepipeline
• 还有很多...

在本文中，您将学习如何使用 GitHub Actions 定义您的流水线，这将使您能够配置流水线，以便在您向主分支创建拉取请求时针对代码更改运行。

您将使用的技术

• Node.js
• GitHub Actions
• Docker
• Postgres
• PNPM

前提条件

假定知识

在执行以下步骤时，具备以下知识会有所帮助

• Git 基本使用知识
• Docker 基本理解

开发环境

要跟随提供的示例，您需要具备以下条件：

• Node.js 已安装
• 您选择的代码编辑器（我们推荐 VSCode）
• Git 已安装
• pnpm 已安装
• Docker 已安装

本系列大量使用了此 GitHub 仓库。请确保克隆该仓库。

克隆仓库

在您的终端中，进入您存储项目的目录。在该目录中运行以下命令：

上述命令将把项目克隆到一个名为 testing_mono_repo 的文件夹中。该仓库的默认分支是 main。

您需要切换到 e2e-tests 分支，该分支包含上一篇文章中完整的端到端测试设置

克隆仓库并切换到正确的分支后，还需要几个步骤来设置项目。

首先，安装 node_modules

接下来，在项目根目录创建 .env 文件

向该新文件添加以下变量：

在 .env 文件中，添加了以下变量：

• API_SECRET: 提供一个用于身份验证服务加密密码的密钥。在实际应用中，此值应替换为一个包含数字和字母的随机长字符串。
• DATABASE_URL: 包含您的数据库 URL。
• VITE_API_URL: Express API 的 URL 地址。

设置您自己的 GitHub 仓库

为了开始配置在 GitHub Actions 中运行的流水线，您首先需要一个自己的 GitHub 仓库，该仓库有一个 main 分支，用于提交拉取请求。

访问 GitHub 网站并登录您的账户。

注意：如果您还没有 GitHub 账户，可以在此处免费创建一个。

登录后，点击下方所示的新建按钮来创建一个新仓库

在下一页，您将需要填写一些关于仓库的信息。填写下方所示的字段，然后点击页面底部的创建仓库按钮

然后，您将导航到新仓库的主页。顶部会有一个文本字段，允许您复制仓库的 URL。点击复制图标以复制 URL

现在您有了新 GitHub 仓库的 URL，进入代码库的根目录，在终端中使用以下命令更改项目的origin以指向新仓库（请务必在第二行插入您刚刚复制的 URL）

您将基于 e2e-tests 分支的进展进行工作，因此该分支应被视为 main。将 e2e-tests 合并到 main

最后，将项目推送到您的新仓库

设置工作流

您现在已经设置好了一个可以推送更改的仓库。下一个目标是，每当针对您已创建的 main 分支进行拉取请求或更新时，触发一系列任务。

使用 GitHub 时，您可以创建 工作流 文件来定义这些步骤。这些文件必须创建在项目根目录下的 .github/workflows 文件夹中。

在您的项目中创建一个名为 .github 的新文件夹

在 .github/workflows 文件夹中，创建一个新文件来定义您的测试工作流，文件名为 test.yml

在此文件中，您将提供 GitHub Actions 应采取的步骤来准备项目并运行您的测试套件。

为了开始这个工作流，使用 name 属性为您的工作流命名

该工作流现在将在 GitHub 中显示为 'Tests'。

接下来要做的是配置此工作流，使其仅在针对仓库的 main 分支进行拉取请求时运行。添加带有以下选项的 on 关键字来实现此目的

注意：请注意缩进。缩进在 YAML 文件中非常重要，错误的缩进会导致文件失败。

您现在已经命名了您的工作流，并配置它仅在针对 main 进行拉取请求或更新时运行。接下来，您将开始定义一个运行单元测试的作业。

注意：工作流文件中有很多选项可以配置，用于更改工作流的运行方式、功能等……有关完整列表，请查阅 GitHub 的文档。

添加单元测试作业

要在工作流中定义与特定任务相关的一系列指令（称为步骤），您将使用 job 关键字。每个作业都在您配置的独立环境中运行其步骤集。

在 .github/workflows/tests.yml 文件中添加一个 jobs 部分，并指定一个名为 unit-tests 的作业

如前所述，每个单独的作业都在其自己的环境中运行。为了运行作业，您需要指定作业应运行在何种类型的机器上。

使用 runs-on 关键字指定作业应在 ubuntu-latest 机器上运行

设置单元测试作业的最后一个部分是 steps 部分，您将在其中定义作业为运行单元测试应采取的一系列步骤。

将以下内容添加到 unit-tests 作业中

这定义了一个包含一个步骤的 steps 部分。这个步骤使用 v3 版本的预构建操作 actions/checkout，它会检出您的 GitHub 仓库，以便您可以在作业内部与其交互。

注意：一个 操作 是一系列您可以在工作流中使用的独立步骤。它们有助于将可重用的步骤集分解到一个文件中。

接下来，您需要定义一系列步骤，用于在虚拟环境中安装 Node.js，安装 PNPM，以及安装您仓库的包。

您创建的每个测试作业都需要这些步骤，因此您将在一个可重用的自定义操作中定义它们。

在 .github 目录中创建一个名为 actions 的新文件夹，并在 .github/actions 文件夹中创建一个 build 文件夹

然后在 .github/actions/build 内部创建一个名为 action.yml 的文件

在该文件中，粘贴以下内容：

此文件定义了一个复合操作，它允许您在作业中使用此操作中定义的 steps。

您在上面添加的步骤执行以下操作：

1. 在虚拟环境中设置 PNPM
2. 在虚拟环境中设置 Node.js
3. 在仓库中运行 pnpm install 以安装 node_modules

定义了这个可重用操作后，您可以在主工作流文件中使用它。

返回 .github/workflows/tests.yml，使用 uses 关键字来使用该自定义操作

至此，作业将检出仓库，设置虚拟环境并安装 node_modules。剩下要做的就是实际运行测试。

添加最后一个步骤来运行 pnpm test:backend:unit 以执行单元测试

注意：注意您使用 name 关键字将此新步骤命名为 'Run tests'，并使用 run 关键字运行了一个任意命令。

此作业现已完成并准备好进行测试。为了测试，首先将此代码推送到您仓库的 main 分支

工作流现已在 main 分支上定义。但是，只有当您针对该分支提交拉取请求时，工作流才会被触发。

创建一个名为 new-branch 的新分支

在该新分支中，通过向 backend/src/index.ts 文件添加注释来做一些小更改

现在提交并将这些更改推送到远程仓库。仓库当前不知道 new-branch 分支，因此您需要指定origin应使用名为 new-branch 的分支来处理这些更改

新分支现已在远程仓库中可用。创建一个拉取请求，将此分支合并到 main 分支。

在浏览器中访问该仓库。在页面顶部的拉取请求选项卡中，您应该会看到一个比较和拉取请求按钮，因为 new-branch 最近有推送。

点击该按钮打开一个拉取请求。您将被导航到一个新页面。在该新页面上，点击创建拉取请求按钮来打开一个拉取请求。

打开拉取请求后，您应该会在合并拉取请求按钮上方看到一个黄色框，显示您的测试作业正在运行。

如果您点击详情按钮，您应该会看到每个步骤的运行情况及其控制台输出。

作业完成后，您将收到通知，告知您的工作流中的检查是否通过

现在您的单元测试作业已完成，接下来将创建运行集成测试的作业。

注意：暂不要合并此拉取请求！您将在本文的其余部分重新使用此拉取请求。

添加集成测试作业

运行集成测试的过程将与运行单元测试非常相似。此作业的不同之处在于，您的集成测试依赖于测试数据库和环境变量。在本节中，您将设置这些，并定义一个作业来运行您的测试。

在开始进行更改之前，您需要再次检出仓库的 main 分支

首先，将 unit-tests 作业复制到一个名为 integration-tests 的新作业中。此外，在此作业的最后一步中，将 pnpm test:backend:unit 替换为 pnpm test:backend:int

至此，您已经具备了运行测试所需的大部分要素，但按原样运行工作流会触发 scripts/run-integration.sh 文件运行。该脚本使用 Docker Compose 启动一个测试数据库。

GitHub Actions 使用的虚拟环境默认不带 Docker Compose。为了使其工作，您需要设置另一个自定义操作，将 Docker Compose 安装到环境中。

在 .github/actions 中创建一个名为 docker-compose 的新文件夹，并在其中创建一个名为 action.yml 的文件

这个操作应该做两件事：

1. 将 Docker Compose 插件下载到虚拟环境中
2. 使插件可执行，以便可以使用 docker-compose 命令

将以下内容粘贴到 .github/actions/docker-compose/action.yml 中来处理这些任务

上述代码片段中的第一步将 Docker Compose 插件源下载到虚拟环境中的 /usr/local/bin/docker-compose。然后它使用 chmod 将此源设置为可执行文件。

自定义操作完成后，将其添加到 .github/workflows/tests.yml 中的 integration-tests 作业中，就在运行测试的步骤之前

此测试需要的最后一件事是一组环境变量。您的应用程序期望的环境变量是：

• DATABASE_URL: 数据库的 URL
• API_SECRET: 用于签名 JWTs 的认证密钥
• VITE_API_URL: Express API 的 URL

您可以使用 env 关键字将这些添加到虚拟环境中。环境变量可以在工作流级别添加（应用于所有作业），也可以添加到特定作业。在本文中，为了简单起见，变量将在工作流级别添加，以便所有作业都能访问。

注意：通常的最佳实践是仅将必需的环境变量单独暴露给每个作业。在本文中，为了简单起见，变量将暴露给所有作业。

将 env 键添加到您的工作流中，并定义您需要的三个变量

此时，您可以提交并将这些更改推送到 main 分支，以发布对工作流的更改

然后通过运行以下命令将这些更改合并到 new-branch 分支中，以触发工作流的新运行

注意：在 git merge main 步骤，您将在终端中进入一个编辑器。按 :qa 和 回车 键退出该编辑器。

这个作业将比单元测试作业花费更多时间，因为它必须安装 Docker Compose，启动数据库，然后执行所有测试。

作业完成后，您应该会看到以下成功消息

添加端到端测试作业

现在单元测试和集成测试都在工作流中运行了，最后需要定义的测试是端到端测试。

首先，再次检出 main 分支，以便更改工作流文件

与上一节的开头类似，将 integration-tests 作业的内容复制到一个名为 e2e-tests 的新作业中，并将 pnpm backend:tests:int 替换为 pnpm test:e2e

在提交新作业之前，还有几件事要做

• 在虚拟环境中安装 Playwright 及其测试浏览器
• 更新 scripts/run-e2e.sh

在此作业中安装 Docker Compose 的步骤之后，立即添加两个新步骤，用于下载 Playwright 并将其测试浏览器安装到项目中的 e2e 文件夹中

您还需要在 env 部分添加两个新的环境变量，这些变量将在安装 Playwright 时使用

现在，当工作流运行时，Playwright 应该已正确安装和配置，以便您的测试能够运行。

接下来要更改的是 scripts/run-e2e.sh 脚本运行端到端测试的方式。

目前，端到端测试运行完成后，脚本会自动使用 npx playwright show-report 提供生成的报告。在 CI 环境中，您不希望发生这种情况，因为它会导致作业无限期运行，直到手动取消。

从脚本中移除该行

问题解决后，您现在可以推送更改到 main 并将这些更改合并到 new-branch 分支

如果您回到浏览器查看拉取请求，现在应该会看到检查中运行着三个作业。

新作业将花费很长时间才能完成，因为它必须下载 Docker Compose 和 Playwright 的浏览器，启动数据库，然后执行所有测试。

作业完成后，您应该会看到完整的成功测试列表

总结与最终思考

在本文中，您了解了持续集成。更具体地说，您学习了：

• 什么是持续集成
• 它为什么在您的项目中很有用
• 如何使用 GitHub Actions 设置 CI 流水线

最后，您拥有了一个 CI 流水线，可以自动针对与 main 分支相关的任何拉取请求的分支运行您的整个测试套件。

这是强大的，因为它允许您在每个拉取请求上设置检查，以确保相关分支中的更改按预期工作。使用 GitHub 的安全设置，您还可以在这些检查不成功时阻止合并到 main 中。

在本系列文章中，您全面了解了可以对您的应用程序运行的各种测试，如何针对使用 Prisma 与数据库交互的函数和应用程序编写这些测试，以及如何在您的项目中使用这些测试。

如果您对本系列中涵盖的任何内容有任何疑问，请随时在Twitter上与我联系。