Prisma 测试终极指南：端到端测试

目录

• 目录
• 引言
  • 什么是端到端测试？
  • 您将使用的技术
• 先决条件
  • 预备知识
  • 开发环境
  • 克隆仓库
  • 仓库概览
• 设置端到端测试项目
• 安装并初始化 Playwright
• 设置测试环境
• 编写端到端测试
  • 页面对象 (Pages)
  • 测试夹具 (Fixtures)
  • 测试
• 为什么选择 Playwright？
• 总结与下一步

引言

本系列的目前为止，您已经编写了广泛的测试，以确保独立的 Express API 的功能和行为按预期工作。这些测试的形式是集成测试和单元测试。

在本系列这一部分中，您将为这个应用程序增加另一层复杂性。本文将探讨一个 monorepo，其中包含与前几篇文章相同的 Express API 和测试，以及一个使用该 API 的 React 应用程序。本教程的目标是编写端到端测试，确保用户在应用程序中进行的交互正常工作。

什么是端到端测试？

端到端测试是一种广泛的测试方法，专注于模拟应用程序中的用户交互，以确保它们正常工作。

本系列前几部分的测试侧重于验证应用程序的各个构建块是否正常工作，而端到端测试确保用户对应用程序的体验符合预期。

例如，端到端测试可能会检查以下方面

• 如果用户未登录时导航到首页，他们是否会被重定向到登录页面？
• 如果用户通过 UI 删除一条记录，其 HTML 元素是否会消失？
• 用户是否可以在不填写电子邮件字段的情况下提交登录表单？

端到端测试之所以如此有用，是因为它不仅验证了技术栈特定部分的行为，还确保所有部分都按预期协同工作。这些测试不是专门针对前端客户端或后端 API 编写的，而是同时利用两者，并像测试运行器是用户一样进行操作。

有了端到端测试的一般概念，您现在就可以开始设置测试环境了。

您将使用的技术

• Prisma
• Node.js
• Postgres
• Docker
• pnpm
• Playwright

先决条件

预备知识

进行以下步骤时，具备以下知识会很有帮助

• JavaScript 或 TypeScript 的基础知识
• Prisma Client 及其功能的基础知识
• 对 Docker 的基本理解
• 有使用测试框架的经验

开发环境

要跟着提供的示例进行操作，您需要安装

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

本系列大量使用了这个 GitHub 仓库。请务必克隆该仓库。

克隆仓库

在您的终端中，切换到您存放项目的目录。在该目录中运行以下命令

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

克隆仓库后，设置项目需要执行几个步骤。

首先，进入项目目录并安装 node_modules

接着，在项目的根目录创建一个 .env 文件

向该新文件添加以下变量

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

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

仓库概览

如上所述，与本系列前几部分不同，本文中您将使用的仓库是一个 pnpm monorepo，它包含两个独立的应用程序。

下面是项目的文件夹结构

The backend 文件夹包含 Express API 及其集成测试和单元测试。该项目与本系列前面部分中的 API 相同。

The frontend 文件夹包含一个新的前端 React 应用程序。该应用程序已完成，在本系列中不会进行修改。

The prisma 和 scripts 文件夹包含与本系列前几篇文章中相同的文件。prisma/ 包含 schema.prisma 文件，scripts/ 包含帮助运行和设置测试环境的 .sh 脚本。

其余文件定义了包配置、Docker 容器和 pnpm workspace。

如果您查看 package.json，您将在 scripts 部分看到以下内容

这些是可以在 pnpm monorepo 中运行的命令。这里的命令主要使用 pnpm 运行 backend/package.json 和 frontend/package.json 中定义的命令。

从项目根目录运行以下命令来启动应用程序

如果您随后导航到 http//localhost:5173，您应该会看到应用程序的登录页面

接下来，您将开始设置端到端测试及其测试环境。

设置端到端测试项目

要开始设置端到端测试，您将在 monorepo 中设置一个新项目，其中将包含所有端到端测试代码。

注意：您的端到端测试及其相关代码位于 monorepo 中的一个独立项目中，因为这些测试不属于前端或后端项目。它们是一个独立的实体，与这两个项目都进行交互。

此过程的第一步是为您的项目创建一个新文件夹。

在 monorepo 的根目录添加一个名为 e2e 的新文件夹

在该新目录中，您需要使用以下命令初始化 pnpm

此命令将创建一个 package.json 文件，其中包含初始配置，包括一个 name 字段，其值为 'e2e'。该名称将用于 pnpm 定义项目的工作区（workspace）。

在 monorepo 的根目录中，打开 pnpm-workspace.yaml 文件并添加以下内容

您将编写端到端测试的项目现已在 pnpm monorepo 中注册，您已准备好开始设置测试库。

安装并初始化 Playwright

在本文中，您将使用 Playwright 来运行端到端测试。

注意：为什么选择 Playwright 而不是 Cypress 或其他更成熟的工具？Playwright 有一些非常酷的特性，将在本文稍后强调，这些特性使得 Playwright 在此特定用例中脱颖而出。

首先，在 e2e 目录中安装 playwright

运行上述命令后，系统会询问您有关项目的一系列问题。按 回车键使用每个选项的默认设置

注意 'typescript', 'tests', 'true' 和 'true' 是选择的选项。

注意：此过程的安装步骤可能会花费一些时间，因为 Playwright 会安装您的测试将运行的多个浏览器的二进制文件。

此配置设置了项目的总体结构，但它也包含了一些您不需要的文件。

通过运行以下命令删除不需要的文件

注意：您删除的文件只是用于向您展示测试应放在哪里以及如何编写的示例文件。

接下来，由于本项目将使用 TypeScript 编写，请在此文件夹中初始化 TypeScript

至此，您已准备好在此项目中开始编写 TypeScript，并可以使用 Playwright 提供的工具。下一步是配置 Playwright 并编写启动脚本，该脚本将为您的测试启动数据库、前端和后端。

设置测试环境

运行端到端测试主要需要做两件事

1. 配置 Playwright 在运行测试时自动启动前端和后端服务器
2. 添加一个 shell 脚本，用于在运行端到端测试之前启动测试数据库

这些步骤的目标是提供一种方法，通过单个命令来启动数据库、等待数据库上线、启动前端和后端项目的开发服务器，最后运行端到端测试。

配置 Playwright

初始化 Playwright 时，在 e2e 文件夹中生成了一个名为 playwright.config.ts 的新文件。在该文件的最底部，您会找到一个被注释掉的配置选项，名为 webServer。

此配置选项允许您提供一个对象（或对象数组），其中包含在运行测试之前启动 Web 服务器的命令。它还允许您为每个对象提供一个端口号，Playwright 将使用该端口号等待该端口上的服务器变得可用后才开始测试。

您将使用此选项来配置 Playwright 启动后端和前端项目。

在 playwright.config.ts 中，取消注释该部分并添加以下内容

对于上述配置中的每个命令，都使用 pnpm 并通过 --filter 标志运行前端和后端项目中相应的 dev 脚本。这些脚本定义在每个项目的 package.json 文件中。

注意：有关如何在 pnpm 中运行命令的信息，请查看其文档。

每个对象都有一个 reuseExistingServer 键，设置为 true。这告诉 Playwright，如果在运行测试之前已启动了服务器，则应重用该服务器。

编写启动脚本

现在 Playwright 本身已配置为启动开发服务器，您还需要一种方法通过单个命令启动测试数据库以及 Playwright 的测试运行器。

您将使用的方法与本系列前一篇文章中用于在运行集成测试之前启动数据库的脚本非常相似。

进入 monorepo 根目录的 scripts/ 文件夹，创建一个名为 run-e2e.sh 的新文件

您将在此文件中编写启动脚本。

注意：查看 scripts/run-integration.sh 以了解前一篇文章中编写的启动脚本。

该文件首先需要设置为可执行文件，这样您就可以通过终端运行该文件。

将以下内容添加到 run-e2e.sh 的最顶部

注意：此行被称为 shebang 行，用于将 bash 设置为执行命令的默认 shell。

然后，从 monorepo 的根目录运行以下命令，将文件在文件系统中标记为可执行文件

现在文件已可执行，您将开始编写实际的启动脚本。

添加以下行以运行本系列前一篇文章中编写的数据库启动脚本

此脚本将根据项目根目录的 docker-compose.yml 文件启动一个 Docker 容器。然后，它将等待数据库可用，并运行 prisma migrate dev 后才允许脚本继续。

数据库启动后，脚本最后需要做的是运行端到端测试。

将以下内容添加到 run-e2e.sh 的末尾

上面添加的行运行 npx playwright test，它会调用测试运行器。如果调用此脚本的命令提供了任何参数，脚本会假定测试应以可见模式（headed mode）运行，这由 --headed 参数表示。这会导致您的端到端测试在实际浏览器中显示运行过程。

最后，在脚本的末尾，运行 npx playwright show-report，它会启动一个本地开发服务器，并显示一个网页，其中包含测试结果。

脚本完成后，最后一步是配置运行它的方式。

在 e2e 文件夹内的 package.json 中，将以下内容添加到 scripts 部分

由于 prisma 不在此目录中，您还需要在此 package.json 文件中指定 Prisma schema 的位置

如果您的终端已切换到 e2e 文件夹，这允许您运行端到端测试。

为了更简单，请前往 monorepo 根目录的 package.json 文件，并将以下内容添加到 scripts 部分

现在您可以从项目根目录运行端到端测试了。

假设您的终端当前位于 e2e 文件夹中，以下命令将把您导航到项目根目录并运行您的测试脚本

测试报告应该是空的。目前还没有测试！

编写端到端测试

Playwright 已配置好，您的测试环境已准备就绪！现在您将开始为应用程序编写端到端测试。

测试内容

在本文中，您将编写与应用程序认证流程相关的所有内容的端到端测试。

注意：GitHub 仓库的 e2e-tests 分支包含整个应用程序的完整端到端测试套件。

请记住，端到端测试侧重于测试用户可能采取的应用程序工作流程。看看您将为其编写测试的登录页面

尽管可能不那么显而易见，但关于身份验证，用户可能会遇到许多可以测试的场景。

虽然可能不是立即显而易见，但围绕认证，有许多用户可能遇到的场景您可以测试。

• 例如，用户应该
• ... 在未登录时尝试访问首页时被重定向到登录页面。
• ... 在账户成功创建后被重定向到首页。
• ... 在成功登录后被重定向到首页。
• ... 在登录尝试不成功时收到警告。
• ... 在尝试使用已存在的用户名注册时收到警告。
• ... 在提交空表单时收到警告。

... 在退出登录时返回到登录页面。

在本文中，您将仅为其中的几个场景编写测试，以保持文章长度可控。具体来说，本文将涵盖以下场景。

• 例如，用户应该
• ... 在未登录时尝试访问首页时被重定向到登录页面。
• ... 在账户成功创建后被重定向到首页。
• ... 在成功登录后被重定向到首页。
• ... 在尝试使用已存在的用户名注册时收到警告。

用户应该

注意：这些场景将涵盖我们希望在本文中传达的所有主要概念。我们也鼓励您自行尝试为其他场景编写测试！

测试示例

Playwright 提供了丰富的助手和工具库，让您可以非常直观地测试您的应用程序。

看看下面的示例测试，用于一个假设的应用，它允许您在公告板上发布消息

上面的测试验证了当您发布消息时，它会自动显示在网页上。

为了实现这一点，测试必须遵循用户为达到预期结果而采取的流程。更具体地说，测试必须

1. 使用测试账户登录
2. 提交帖子
3. 验证帖子已显示在网页上

您可能已经注意到，很多这些步骤，例如登录，最终可能会重复很多次。特别是在包含数十个（或更多）需要登录用户的测试套件中。

为了避免在每个测试中重复指令集，您将利用两个概念将这些指令分组为可重用的块。这些是页面对象（pages）和测试夹具（fixtures）。

页面对象 (Pages)

首先，您将为登录页面设置一个页面对象（page）。这本质上只是一个助手类，它将与网页的各种交互集分组到类的各个成员函数中，这些函数最终将由测试夹具（fixtures）和您的测试本身使用。

在 e2e/tests 文件夹内，创建一个名为 pages 的新文件夹

在该文件夹内，创建一个名为 login.page.ts 的新文件

您将在这里定义描述您的登录页面的类。

在该文件的最顶部，导入 Playwright 提供的 Page 类型

这个助手类型描述了一个可用于 Playwright 中所有注册测试的测试夹具（fixture），名为 page。page 对象代表浏览器中的单个标签页。您正在编写的类将在其构造函数中需要此 page 对象，以便它可以与浏览器页面交互。

在 login.page.ts 中，添加并导出名为 LoginPage 的类，其构造函数接受类型为 Page 的 page 参数

有了浏览器页面的访问权限，您现在可以定义特定于此页面的可重用交互。

首先，添加一个名为 goto 的成员函数，用于导航到应用程序的 /login 页面

注意：有关 page 对象的可用函数信息，请查看 Playwright 的文档。

接下来，添加第二个函数，用于填写登录表单

对于本教程，这是登录页面所需的唯一可重用指令集。

接下来，您将使用一个测试夹具（fixture）将此 LoginPage 类的实例暴露给您的每个测试。

测试夹具 (Fixtures)

回顾上面所示的测试示例

在这里，从 test 函数回调函数的参数中解构出了一个 page 对象。这是 Playwright 提供的、在上一节中引用的同一个测试夹具（fixture）。

Playwright 提供了一个 API，允许您扩展现有的 test 函数以提供自定义测试夹具。在本节中，您将编写一个测试夹具，用于向您的每个测试提供 LoginPage 类。

登录页面测试夹具

从 monorepo 根目录开始，在 e2e/tests 中创建一个名为 fixtures 的新文件夹

然后，在该新文件夹中创建一个名为 auth.fixture.ts 的文件

在该文件的最顶部，使用别名 base 导入 Playwright 的 test 函数

此处导入的变量是默认的 test 函数，您将通过自定义测试夹具扩展它。然而，在扩展此函数之前，您需要定义一个 type 来描述您将添加的测试夹具。

添加以下内容来描述一个名为 loginPage 的测试夹具，它会为您的测试提供 LoginPage 类的一个实例

您现在可以使用该类型来扩展 test 函数的类型

在 base.extend 函数的对象参数中，您现在会发现有 IntelliSense 描述一个 loginPage 属性。

此属性是您定义新的自定义测试夹具（custom fixture）的地方。其值将是一个带有两个参数的异步函数

1. 一个包含所有可用于 test 函数的夹具（fixtures）的对象。
2. 一个 use 函数，它接受一个 LoginPage 实例作为其唯一参数。此函数会将 LoginPage 类的实例提供给所有测试。

此函数的主体应使用 page 夹具实例化 LoginPage 类。然后，它应调用实例化类的 goto 函数。这将使登录页成为浏览器使用 loginPage 夹具时的起始点。最后，应使用 loginPage 变量作为输入调用 use 函数，将实例提供给使用新夹具的测试。

以下更新实现了上述更改

这里要做的最后一件事是也导出一个名为 expect 的函数，这是 Playwright 提供的一个函数，允许您为测试设置预期。这将允许您从同一位置轻松导入 test 和 expect。

将 expect 导出添加到文件底部

您的第一个自定义夹具已完成，并准备好在测试中使用！不过在此之前，您的测试套件还需要在测试数据库中存在一个用户，以验证身份验证功能是否正常工作。为此，您需要添加更多处理以下内容的夹具：

• 为每个测试生成唯一的登录凭据
• 为每个测试创建测试账户
• 提供对测试上下文的本地存储数据的访问
• 在每次测试之间清理测试数据

用户凭据夹具

首先创建一个夹具，为每个测试生成唯一的登录凭据。

在 e2e/fixtures/auth.fixture.ts 中，在 import 语句下方添加一个名为 UserDetails 的 type，其中包含 username 和 password 属性

在 AuthFixtures 类型中使用此类型描述一个新的 user_credentials 属性

您的 test 对象现在可以处理 user_credentials 夹具。此夹具将执行以下三件事：

1. 生成随机用户名和密码
2. 为每个测试提供一个包含用户名和密码的对象
3. 使用 Prisma 从数据库中删除所有具有生成用户名的用户

该夹具将使用 Faker 生成随机数据，因此您首先需要在 e2e 文件夹中安装 Faker 库

此夹具中生成的凭据通常会用于通过 UI 创建新账户。为避免在测试数据库中留下陈旧数据，您需要在测试之间清理这些账户。

Playwright 的一个很酷之处在于它在 Node 运行时中运行，这意味着您可以在测试和夹具中使用 Prisma Client 与数据库交互。您将利用这一点来清理测试账户。

在 e2e/tests 文件夹中创建一个名为 helpers 的新文件夹，并添加一个名为 prisma.ts 的文件。导航回 monorepo 的根目录并运行以下命令：

在新文件中，导入 PrismaClient 并导出实例化的客户端

在 auth.fixture.ts 文件的顶部导入 prisma 和 faker

您现在拥有编写 user_credentials 夹具所需的所有工具。

将以下内容添加到 test 对象的夹具集中，以定义生成、提供和清理测试凭据的夹具

注意: 此处使用 Prisma 删除生成的用户，以防凭据用于创建数据。这将在每次测试结束时运行。

您现在可以在测试中使用此夹具来访问一组唯一的凭据。这些凭据与数据库中的用户尚无任何关联。

账户夹具

为了让您的测试能够访问真实用户，您将创建另一个名为 account 的夹具，该夹具将使用生成的凭据创建一个新账户，并将这些详细信息提供给测试。

此夹具将需要您的自定义 user_credentials 夹具。它将使用这些凭据填写注册表单并使用唯一的凭据提交表单。

此夹具将提供给测试的数据是一个包含新用户用户名和密码的对象。

在 AuthFixtures 类型中添加新行，名为 account，其类型为 UserDetails

然后将以下夹具添加到 test 对象

在测试中使用此夹具将为您提供数据库中存在的用户的凭据。在测试结束时，该用户将被删除，因为此夹具需要 user_credentials 夹具，从而触发清理 Prisma 查询。

本地存储夹具

您需要执行应用程序身份验证测试的最后一个夹具应该让您访问测试浏览器的本地存储数据。

当用户登录应用程序时，其信息和身份验证令牌存储在本地存储中。您的测试需要读取该数据以确保数据成功存储。

注意: 此数据可以直接从测试中访问（虽然很繁琐）。创建夹具来提供此数据只是为了让数据更容易访问。

在 e2e/tests/helpers 文件夹中，创建一个名为 LocalStorage.ts 的新文件

在该文件中，导入 Playwright 提供的 BrowserContext 类型

为了提供本地存储访问，您将把另一个名为 context 的夹具包装在一个类中。此过程类似于您之前编写的包装 page 夹具的类。

将以下代码片段添加到 LocalStorage.ts 文件

在此类中，添加一个使用 context 夹具的 storageState 函数访问在 http://localhost:5173 运行的站点的浏览器上下文本地存储数据的 getter 函数

注意: 请查阅 Playwright 关于 context 对象的文档，以更好地理解上述代码。

此类为您提供了一种轻松访问本地存储的方法，但是，数据仍然需要通过夹具提供给您的测试。

回到 auth.fixtures.ts 中，导入 LocalStorage 类

接下来，在 AuthFixtures 类型中添加另一个名为 storage 的属性，其类型为 LocalStorage

最后，添加一个新夹具，该夹具使用 page 夹具的 context 实例化 LocalStorage 类，并使用 use 函数将其提供给您的测试

此夹具完成后，您现在可以处理下一节中将测试的所有场景了。

注意: 在 GitHub 仓库的 e2e-tests 分支中，您会注意到夹具的设置略有不同。本文中以下几点不同是为了阐明夹具和页面的作用：

• 未使用 TypeScript 别名来缩短导入 URL
• 由于本文中只使用了一个夹具文件，因此没有使用 base.fixture.ts 文件作为 auth.fixture.ts 文件的基础夹具来在文件之间共享属性

测试

您将编写的第一个测试将验证未登录的用户尝试访问主页时是否会被重定向到登录屏幕。

验证未经授权的用户是否被重定向到登录屏幕

首先，在 e2e/tests 中创建一个名为 auth.spec.ts 的新文件

在该文件的顶部，从 auth.fixture.ts 文件导入 test 和 expect 变量

现在您已经可以访问自定义的 test 对象了，使用它的 describe 函数来描述您的测试套件

第一个测试不需要使用自定义的 loginPage 夹具，因为它不会从登录页开始。相反，您将使用默认的 page 夹具，尝试访问主页并验证页面是否被重定向到登录屏幕。

添加以下测试来完成此任务

如果您现在运行您的测试套件，您应该会看到一个成功的测试

您将看到三行，因为您的测试默认在三种不同的浏览器中运行。

注意: 如果您收到包含以下文本的错误：'browserType.launch: Executable does not exist at ...'，请尝试在 e2e 文件夹中运行 npx playwright install。然后再次运行您的测试。如果目标浏览器未下载，则会发生此错误。

验证用户使用错误凭据登录时是否收到警告

在应用程序的登录页面上，如果用户尝试使用错误凭据登录，屏幕上应弹出一个消息，告知他们出现了问题。在此测试中，您将验证该功能是否正常工作。

请注意右下角的弹出窗口。

要开始此测试，向测试套件添加一个 test，其中包含 page 和 loginPage 夹具

注意: 由于此测试中包含了 loginPage 夹具，测试页面将从应用程序的登录页开始。

接下来，使用 LoginPage 类的 populateForm 函数填充包含无效登录凭据的登录表单

最后，使用 page 对象的 click 函数点击登录按钮，等待请求完成并验证弹出窗口出现

运行端到端测试现在应该会显示另一组成功的测试

验证用户尝试提交空表单时是否收到警告

此测试与上一个测试非常相似，因为它将从登录页开始并提交登录表单。唯一的区别是表单应为空，并且错误消息应包含文本：'Please enter a username and password'。

添加以下测试来验证是否显示了预期的错误消息

注意:在此测试中，通过 loginPage.page 属性访问 click 函数。这样做纯粹是为了消除当变量未使用时出现的 ESLint 警告。

运行端到端测试现在应该会显示第三组成功的测试

验证用户创建新账户后是否被重定向到主页

到目前为止，您编写的测试都假设用户未登录或无法登录。

在此测试中，您将验证用户通过注册表单成功创建新账户后是否会被重定向到主页。

向测试套件添加一个新测试，其中包含 user_credentials、loginPage、storage 和 page 夹具

此测试需要做的第一件事是使用唯一的凭据填写注册表单。user_credentials 夹具包含此测试独有的数据，因此您将使用这些值。

添加以下代码片段来填充注册表单并提交

此时，测试将填充注册表单并点击注册按钮。发生这种情况时，浏览器应被重定向到主页，并且用户详细信息应以名为 'quoots-user' 的键存储在本地存储中。

添加以下内容以验证重定向是否发生以及用户数据是否可在本地存储中获取

如果一切顺利，当您运行时应该会看到第四组成功的测试

注意: 请记住，此测试期间创建的测试账户在测试完成后会被清理。要验证这一点，请尝试在 e2e/tests/helpers/prisma.ts 中开启查询日志记录，然后再次运行测试以查看清理查询。

验证用户登录后是否被重定向到主页

这个最后的测试与上一个测试类似，但它假设数据库中已经存在一个用户账户。它将执行登录操作而不是创建新账户，并验证用户最终停留在主页上。

因为您需要生成新账户而不仅仅是一组唯一的凭据，所以此测试应包含 account 夹具而不是 user_credentials 夹具

此测试的说明集几乎与上一个测试相同，不同之处在于您将使用 account 对象的值来填充登录表单，而不是使用 user_credentials 的值

如果您现在运行测试套件，您应该会看到第五组成功的测试

为什么选择 Playwright？

市面上有大量工具可帮助您编写和运行端到端测试。其中许多工具已经非常成熟，并且在它们旨在完成的任务上做得很好。

那么……为什么本文使用了相对较新的端到端测试工具 Playwright，而不是更成熟的工具呢？

本文选择 Playwright 作为首选工具有几个原因

• 易用性
• 可扩展的 API
• 灵活的夹具系统

在本文中，您编写的测试的一个重要方面是实现了夹具（fixtures），它允许您设置特定于测试的数据并在之后清理这些数据。

由于 Playwright 直观且可扩展的夹具系统，您可以在这些夹具中直接导入和使用 Prisma Client 来在数据库中创建和删除数据。

可扩展性和开发者体验是我们在 Prisma 非常重视的。Playwright 及其夹具的易于使用和直观的扩展体验在决定选择哪个工具时发挥了重要作用。

注意: 这并不是说其他任何工具“不好”。上述观点仅仅是表达 Playwright 在本文中提出的特定用例中非常适用。

总结与展望

端到端测试使您能够自动化原本需要手动进行的测试。通过一系列指令，您可以导航应用程序并确保期望的行为正常工作。

在本文中，您

• 了解了什么是端到端测试
• 在 pnpm 中设置了一个项目来存放您的端到端测试
• 配置并编写了测试环境脚本
• 创建了夹具（fixtures）和页面对象（pages）以避免测试中的代码重复
• 编写了一系列测试来验证应用程序的身份验证工作流程

本教程内容丰富！我们鼓励您查看GitHub 仓库，查看涵盖整个应用程序的完整端到端测试套件。

在本系列的下一个也是最后一个部分中，您将设置一个 CI/CD 流水线，当您将更改推送到 GitHub 仓库时，该流水线将运行您的单元测试、集成测试和端到端测试。