Prisma 测试终极指南：CI 流水线

目录

• 目录
• 简介
  • 什么是持续集成流水线？
  • 您将使用的技术
• 先决条件
  • 假设的知识
  • 开发环境
  • 克隆仓库
• 设置您自己的 GitHub 仓库
• 设置工作流程
• 添加单元测试作业
• 添加集成测试作业
• 添加端到端测试作业
• 总结与最终想法

简介

当您来到本系列的结尾时，请退后一步，思考一下您在过去四篇文章中完成了什么。您

1. 模拟了 Prisma 客户端
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 帐户，可以在此处创建一个免费帐户。

登录后，单击下面指示的 New 按钮以创建一个新仓库

在下一页中，系统将要求您提供有关仓库的一些信息。填写下面指示的字段，然后单击页面底部的 Create repository 按钮

然后，您将被导航到新仓库的主页。顶部会有一个文本字段，您可以在其中复制仓库的 URL。单击复制图标以复制 URL

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

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

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

设置工作流程

您现在已设置好仓库，可以向其推送更改。下一个目标是在针对您已创建的 main 分支创建或更新拉取请求时，触发一组任务。

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

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

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

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

要启动此工作流程，请使用 name 属性为您的工作流程命名

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

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

注意：注意缩进。缩进在 YAML 文件中非常重要，不正确的缩进会导致文件失败。

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

注意：工作流程文件中有很多选项可以配置，这些选项会更改工作流程的运行方式、工作流程的作用等等... 有关完整列表，请查看 GitHub 的文档。

添加单元测试作业

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

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

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

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

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

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

这定义了一个带有单一步骤的 steps 部分。该步骤使用名为 actions/checkout 的预构建操作的 v3 版本，该版本检出您的 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 分支中。

前往浏览器中的仓库。在页面顶部的 Pull requests 选项卡中，您应该看到 Compare & pull request 按钮，因为 new-branch 最近进行了一次推送

单击该按钮以打开拉取请求。您应该被导航到一个新页面。在该新页面上，单击 Create pull request 按钮以打开拉取请求

打开拉取请求后，您应该在 Merge pull request 按钮上方看到一个黄色框，显示您的 Tests 作业正在运行

如果您单击 Details 按钮，您应该看到每个步骤都在运行及其控制台输出。

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

现在您的单元测试作业已完成，您将继续创建一个运行集成测试的作业。

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

添加集成测试作业

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

在开始进行更改之前，您需要再次检出仓库的 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：用于签署 JWT 的身份验证密钥
• VITE_API_URL：Express API 的 URL

您可以使用 env 关键字将这些添加到虚拟环境中。环境变量可以添加到工作流程级别，这会将它们应用于每个作业，也可以添加到特定作业。在您的情况下，您将在工作流程级别添加它们，以便变量在每个作业中都可用。

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

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

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

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

注意：在 git merge main 步骤中，您将进入终端中的编辑器。点击 :qa 和 enter 以退出该编辑器。

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

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

添加端到端测试作业

现在单元测试和集成测试正在工作流程中运行，要定义的最后一组测试是端到端测试。

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

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

在提交新作业之前，需要执行几项操作

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

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

您还需要向 env 部分添加两个新的环境变量，Playwright 在安装 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 上联系我。