端到端测试是测试应用程序的更“宏观”的形式之一,因为它允许您从用户的角度测试与应用程序的交互。在本文中,您将了解一些关于设置和编写端到端测试的实际示例。
目录
简介
在本系列的这一点上,您已经编写了大量的测试,以确保独立 Express API 的功能和行为按预期工作。这些测试以集成测试和单元测试的形式出现。
在本系列的部分中,您将为此应用程序添加另一层复杂性。本文将探讨一个包含与之前文章中相同的 Express API 和测试的 monorepo,以及一个使用该 API 的 React 应用程序。本教程的目标是编写端到端测试,以确保用户在您的应用程序中所做的交互能够正确工作。
什么是端到端测试?
端到端测试是一种广泛的测试方法,专注于模拟应用程序中的用户交互,以确保它们能够正确工作。
虽然本系列前面部分的测试侧重于验证应用程序的各个构建块是否正常工作,但端到端测试确保用户对您应用程序的体验符合您的预期。
例如,端到端测试可能会检查以下事项
- 如果用户在未登录的情况下导航到主页,他们是否会被重定向到登录页面?
- 如果用户通过 UI 删除记录,其 HTML 元素是否会消失?
- 用户是否可以在不填写电子邮件字段的情况下提交登录表单?
端到端测试如此有用的原因是,它不仅验证了您技术堆栈特定部分的行为,还确保所有部分都按预期协同工作。这些测试不是专门针对前端客户端或后端 API 编写的,而是同时利用两者,并且就像测试运行器是用户一样。
了解了端到端测试的一般概念后,您现在可以开始设置您的测试环境了。
您将使用的技术
先决条件
假设知识
在完成以下步骤时,具备以下知识将很有帮助
- JavaScript 或 TypeScript 的基本知识
- Prisma Client 及其功能的基本知识
- Docker 的基本理解
- 一些使用测试框架的经验
开发环境
要按照提供的示例进行操作,您需要具备
本系列大量使用了这个 GitHub 仓库。请务必克隆该仓库。
克隆仓库
在您的终端中,转到您存储项目的目录。在该目录中运行以下命令
上面的命令会将项目克隆到一个名为 testing_mono_repo
的文件夹中。该仓库的默认分支是 main
。
克隆仓库后,需要执行几个步骤来设置项目。
首先,导航到项目并安装 node_modules
接下来,在项目的根目录创建一个 .env
文件
将以下变量添加到新文件中
在 .env
文件中,添加了以下变量
API_SECRET
:提供身份验证服务用于加密密码的密钥。在实际应用程序中,此值应替换为包含数字和字母字符的长随机字符串。DATABASE_URL
:包含数据库的 URL。VITE_API_URL
:Express API 的 URL 位置。
仓库概览
如上所述,与本系列的前面部分不同,您将在本文中使用的仓库是一个 pnpm monorepo,其中包含两个独立的应用程序。
下面是项目的文件夹结构
backend
文件夹包含 Express API 及其集成和单元测试。此项目与本系列前面部分中使用的 API 相同。
frontend
文件夹包含一个新的前端 React 应用程序。该应用程序已完成,在本系列中不会进行修改。
prisma
和 scripts
文件夹包含与本系列前面文章中相同的文件。prisma/
包含 schema.prisma
文件,scripts/
包含 .sh
脚本,这些脚本有助于运行和设置测试环境。
其余文件定义了包配置、Docker 容器和 pnpm 工作区。
如果您查看 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 将用于定义项目工作区的名称。
在 monorepo 的根目录中,打开 pnpm-workspace.yaml
文件并添加以下内容
您将在其中编写端到端测试的项目现在已在您的 pnpm monorepo 中注册,您可以开始设置您的测试库了。
安装和初始化 Playwright
在本文中,您将使用 Playwright 运行您的端到端测试。
注意:为什么选择 Playwright 而不是 Cypress 或其他更成熟的工具?Playwright 有一些非常酷的功能,将在本文稍后突出显示,这些功能使 Playwright 在此特定用例中脱颖而出。
首先,在 e2e
目录中安装 playwright
运行上述命令后,系统会询问您一系列关于项目的问题。对于每个选项,使用默认值,方法是按 Return 键

请注意,“typescript”、“tests”和“true”以及“true”是所选选项。
注意:此过程的安装步骤可能需要一段时间,因为 Playwright 会安装多个浏览器(您的测试将在其中运行)的二进制文件。
此配置设置了项目的一般结构,但是,它也包含一些您不需要的文件。
通过运行以下命令删除不需要的文件
注意:您删除的文件只是示例文件,用于向您展示测试应该放在哪里以及如何编写测试。
接下来,由于此项目将使用 TypeScript 编写,因此在此文件夹中初始化 TypeScript
此时,您已准备好在此项目中开始编写 TypeScript,并且可以访问 Playwright 提供的工具。下一步是配置 Playwright 并编写一个启动脚本,该脚本将为您的测试启动数据库、前端和后端。
设置测试环境
运行端到端测试需要两个主要事项
- 配置 Playwright 以在运行测试时自动启动前端和后端服务器
- 添加一个 shell 脚本,该脚本在运行端到端测试之前启动测试数据库
这些步骤的目标是提供一种方法,通过运行单个命令来启动数据库,等待数据库联机,启动前端和后端项目的开发服务器,最后运行端到端测试。
配置 Playwright
当您初始化 Playwright 时,在 e2e
文件夹中生成了一个名为 playwright.config.ts
的新文件。在该文件的最底部,您会找到一个被注释掉的名为 webServer
的配置选项。
此配置选项允许您提供一个对象(或对象数组),其中包含在测试运行之前启动 Web 服务器的命令。它还允许您为每个对象提供一个端口号,Playwright 将使用该端口号来等待该端口上的服务器变得可访问,然后再开始测试。
您将使用此选项配置 Playwright 以启动您的后端和前端项目。
在 playwright.config.ts
中,取消注释该部分并添加以下内容
对于上述配置中的每个命令,pnpm 都用于使用 --filter
标志在前端和后端项目中运行相应的 dev
脚本。这些脚本在每个项目的 package.json
文件中定义。
注意:有关如何在 pnpm 中运行命令的信息,请查看他们的文档。
每个对象都有一个设置为 true
的 reuseExistingServer
键。这让 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
参数表示。这将使您的端到端测试在实际浏览器中显示运行。
最后,在脚本末尾,运行 npx playwright show-report
,这将启动一个本地开发服务器,其中包含一个网页,用于显示您的测试结果。
脚本完成后,最后一步是配置一种运行它的方法。
在 e2e
文件夹中的 package.json
中,将以下内容添加到 scripts
部分
由于 prisma
不在此目录中,因此您还需要在此 package.json
文件中指定 Prisma 模式的位置
如果您的终端导航到 e2e
文件夹,这将允许您运行端到端测试。
为了使此操作更简单,请转到 monorepo 根目录下的 package.json
文件,并将以下内容添加到 scripts
部分
现在您可以从项目的根目录运行端到端测试。
假设您的终端当前位于 e2e
文件夹中,以下命令会将您导航到项目的根目录并运行您的测试脚本

测试报告应该是空的。没有测试!
编写端到端测试
Playwright 已配置,您的测试环境已准备就绪!您现在将开始为应用程序编写端到端测试。
要测试什么
在本文中,您将为与应用程序的身份验证工作流程相关的所有内容编写端到端测试。
注意:GitHub 仓库的
e2e-tests
分支包含整个应用程序的完整端到端测试套件。
请记住,端到端测试侧重于测试用户可能采取的应用程序工作流程。查看您将为其编写测试的登录页面

虽然可能不是很明显,但您可以测试用户可能遇到的许多关于身份验证的场景。
例如,用户应该
- ... 如果尝试在未登录的情况下访问主页,则重定向到登录页面。
- ... 在成功创建帐户后,重定向到主页。
- ... 在成功登录后,重定向到主页。
- ... 如果登录尝试不成功,则发出警告。
- ... 如果尝试使用现有用户名注册,则发出警告。
- ... 如果提交空表单,则发出警告。
- ... 注销时返回到登录页面。
在本文中,您将仅为其中一些场景编写测试,以使内容长度可控。具体来说,您将在本文中介绍以下场景。
用户应该
- ... 如果尝试在未登录的情况下访问主页,则重定向到登录页面。
- ... 在成功创建帐户后,重定向到主页。
- ... 在成功登录后,重定向到主页。
- ... 如果登录尝试不成功,则发出警告。
- ... 如果提交空表单,则发出警告。
注意:这些场景将涵盖我们希望在本文中传达的所有主要概念。我们也鼓励您尝试自己编写其他场景的测试!
设置了具体目标后,您现在将开始编写测试。
示例测试
Playwright 提供了大量的帮助程序和工具库,使您能够非常直观地测试您的应用程序。
查看下面的示例测试,该测试用于一个假设的应用程序,该应用程序允许您将消息发布到留言板
上面的测试验证了当您发布消息时,它会自动显示在网页上。
为了实现这一点,测试必须遵循用户为实现预期结果而采取的流程。更具体地说,测试必须
- 使用测试帐户登录
- 提交帖子
- 验证帖子是否显示在网页上
您可能已经注意到,很多这些步骤(例如登录)最终可能会重复很多次。尤其是在包含数十个(或更多)需要登录用户的测试的测试套件中。
为了避免在每个测试中复制指令集,您将使用两个概念,这些概念允许您将这些指令分组到可重用的块中。这些是页面和夹具。
页面
首先,您将为您的登录页面设置一个页面。这本质上只是一个帮助程序类,它将与网页的各种交互集分组到类的各个成员函数中,这些函数最终将被夹具和您的测试本身使用。
在 e2e/tests
文件夹中,创建一个名为 pages
的新文件夹
在该文件夹中,创建一个名为 login.page.ts
的新文件
您将在此处定义描述您的登录页面的类。
在文件的顶部,导入 Playwright 提供的 Page
类型
此帮助程序类型描述了一个名为 page
的夹具,该夹具可用于 Playwright 中注册的所有测试。page
对象表示浏览器中的单个选项卡。您正在编写的类将在其构造函数中需要此 page
对象,以便它可以与浏览器页面进行交互。
在 login.page.ts
中,添加并导出一个名为 LoginPage
的类,其构造函数接受类型为 Page
的 page
参数
通过访问浏览器页面,您现在可以定义特定于此页面的可重用交互。
首先,添加一个名为 goto
的成员函数,该函数导航到应用程序的 /login
页面
注意:有关
page
对象可用功能的信息,请查看 Playwright 的文档。
接下来,添加第二个函数,该函数填写登录表单
对于本教程,这些是登录页面需要的唯一可重用指令集。
接下来,您将使用夹具将此 LoginPage
类的实例公开给您的每个测试。
夹具
回想一下上面显示的示例测试
在此处,page
对象是从 test
函数的回调函数的参数中解构出来的。这与上一节中引用的 Playwright 提供的 夹具 相同。
Playwright 附带一个 API,允许您扩展现有的 test
函数以提供自定义夹具。在本节中,您将编写一个夹具,该夹具允许您将 LoginPage
类提供给您的每个测试。
登录页面夹具
从 monorepo 的根目录开始,在 e2e/tests
中创建一个名为 fixtures
的新文件夹
然后,在该新文件夹中创建一个名为 auth.fixture.ts
的文件
在该文件的顶部,使用名称 base
从 Playwright 导入 test
函数
此处导入的变量是默认的 test
函数,您将使用您的自定义夹具对其进行扩展。但是,在扩展此函数之前,您需要定义一个 type
来描述您将添加的夹具。
添加以下内容以描述一个名为 loginPage
的夹具,该夹具将 LoginPage
类的实例提供给您的测试
您现在可以使用该类型来扩展 test
函数的类型
在 base.extend
函数的对象参数中,您现在会发现您具有描述 loginPage
属性的 IntelliSense。

此属性是您将在其中定义新的自定义夹具的位置。该值将是一个异步函数,带有两个参数
- 一个包含
test
函数的所有可用夹具的对象。 - 一个
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
夹具。此夹具将执行三项操作
- 生成随机用户名和密码
- 为每个测试提供一个包含用户名和密码的对象
- 使用 Prisma 从数据库中删除所有具有生成的用户名的用户
夹具将使用 Faker 生成随机数据,因此您首先需要在 e2e
文件夹中安装 Faker 库
在此夹具中生成的凭据通常用于通过 UI 创建新帐户。为了避免在测试数据库中留下过时的数据,您需要一种方法来清理测试之间的这些帐户。
Playwright 最酷的部分之一是它在 Node 运行时中运行,这意味着您可以使用 Prisma Client 在测试和夹具中与数据库进行交互。您将利用这一点来清理测试帐户。
在 e2e/tests
中创建一个名为 helpers
的新文件夹,并添加一个名为 prisma.ts
的文件。导航回 monorepo 的根目录并运行以下命令
在新文件中,导入 PrismaClient
并导出实例化的客户端
在 auth.fixture.ts
文件的顶部,导入 prisma
和 faker
您现在拥有编写 user_credentials
fixture 所需的所有工具。
将以下内容添加到 test
对象的 fixture 集合中,以定义生成、提供和清理测试凭据的 fixture
注意:此处使用 Prisma 删除生成的用户,以防凭据被用于创建数据。这将会在每次测试结束时运行。
您现在可以在测试中使用此 fixture 来访问一组唯一的凭据。这些凭据尚未以任何方式与数据库中的用户关联。
Account fixture
为了使您的测试能够访问真实用户,您将创建另一个名为 account
的 fixture,该 fixture 将使用生成的凭据创建一个新帐户,并将这些详细信息提供给测试。
此 fixture 将需要您的自定义 user_credentials
fixture。它将使用凭据填写注册表单,并使用唯一的凭据提交表单。
此 fixture 将为测试提供的数据是一个包含新用户的用户名和密码的对象。
在名为 AuthFixtures
的类型中添加新行 account
,其类型为 UserDetails
然后将以下 fixture 添加到 test
对象
在测试中使用此 fixture 将为您提供数据库中已存在的用户的凭据。在测试结束时,用户将被删除,因为此 fixture 需要 user_credentials
fixture,从而触发清理 Prisma 查询。
Local storage fixture
您需要执行应用程序身份验证测试的最后一个 fixture 应该让您能够访问测试浏览器的本地存储数据。
当用户登录应用程序时,他们的信息和身份验证令牌将存储在本地存储中。您的测试将需要读取该数据,以确保数据已成功存储在那里。
注意:可以直接从测试中访问此数据(相当繁琐)。创建一个 fixture 来提供此数据只是使数据更容易访问。
在 e2e/tests/helpers
文件夹中,创建一个名为 LocalStorage.ts
的新文件
在该文件中,导入 Playwright 提供的 BrowserContext
类型
为了提供本地存储访问,您将把另一个名为 context
的 fixture 包装在一个类中。此过程将类似于您之前编写的包装 page
fixture 的类。
将以下代码片段添加到 LocalStorage.ts
文件中
在此类中,添加一个 getter 函数,该函数使用 context
fixture 的 storageState
函数来访问在 http://localhost:5173
运行的站点的浏览器上下文的本地存储数据
注意:查看 Playwright 关于
context
对象的 文档,以更好地理解上面的代码。
此类为您提供了一种轻松访问本地存储的方法,但是,仍然需要通过 fixture 将数据提供给您的测试。
回到 auth.fixtures.ts
中,导入 LocalStorage
类
接下来,向 AuthFixtures
类型添加另一个名为 storage
的属性,其类型为 LocalStorage
最后,添加一个新的 fixture,该 fixture 使用 page
fixture 的 context
实例化 LocalStorage
类,并使用 use
函数将其提供给您的测试
完成此 fixture 后,您现在可以处理下一节中将要测试的每个场景。
注意:在 GitHub 存储库的
e2e-tests
分支中,您会注意到 fixture 的设置略有不同。以下是本文中不同的地方,以阐明 fixture 和页面的角色
- 未使用 TypeScript 别名来缩短导入 URL
- 未将
base.fixture.ts
文件用作auth.fixture.ts
文件的基础 fixture,以在文件之间共享属性,因为本文中仅使用一个 fixture 文件
测试
您将编写的第一个测试将验证未登录的用户尝试访问主页时是否重定向到登录页面。
验证未经授权的用户是否重定向到登录页面
首先,在 e2e/tests
中创建一个名为 auth.spec.ts
的新文件
在此文件的最顶部,从 auth.fixture.ts
文件中导入 test
和 expect
变量
现在您已经可以访问自定义的 test
对象,请使用它的 describe
函数来描述您的测试套件
第一个测试不需要使用自定义的 loginPage
fixture,因为它不会从登录页面开始。相反,您将使用默认的 page
fixture,尝试访问主页并验证页面是否重定向到登录页面。
添加以下测试来完成此操作
如果您现在运行您的测试套件,您应该看到您有一个成功的测试

您将看到三行,因为您的测试默认在三个不同的浏览器中运行。
注意:如果您收到包含以下文本的错误:
'browserType.launch: Executable does not exist at ...'
,请尝试在e2e
文件夹中运行npx playwright install
。然后再次运行您的测试。如果未下载目标浏览器,则会发生此错误。
验证用户使用不正确的凭据登录时是否会收到警告
在应用程序的登录页面上,如果用户尝试使用不正确的凭据登录,则屏幕上应弹出一个消息,告知他们存在问题。在此测试中,您将验证该功能是否正常工作。

请注意右下角的弹出窗口。
要开始此测试,请向测试套件添加一个 test
,该测试引入 page
和 loginPage
fixture
注意:由于此测试中包含了
loginPage
fixture,因此测试页面将从应用程序的登录页面开始。
接下来,使用 LoginPage
类的 populateForm
函数,使用一组无效的登录凭据填写登录表单
最后,使用 page
对象的 click
函数单击登录按钮,等待请求完成并验证是否出现弹出窗口
运行端到端测试现在应该显示另一组成功的测试

验证用户尝试提交空表单时是否会收到警告
此测试将与之前的测试非常相似,因为它将从登录页面开始并提交登录表单。唯一的区别是表单应为空,并且错误消息应包含文本:'Please enter a username and password'
。
添加以下测试以验证是否显示了预期的错误消息
注意:在此测试中,
click
函数是通过loginPage.page
属性访问的。这样做纯粹是为了消除变量未使用时发生的 ESLint 警告。
运行端到端测试现在应该显示第三组成功的测试

验证用户在创建新帐户后是否定向到主页
到目前为止,您编写的测试都假设用户尚未登录或无法登录。
在此测试中,您将验证用户通过注册表单成功创建新帐户后是否重定向到主页。
向套件添加一个新测试,该测试引入 user_credentials
、loginPage
、storage
和 page
fixture
此测试需要做的第一件事是用唯一的用户名和密码填写注册表单。user_credentials
fixture 具有此测试独有的数据,因此您将使用这些值。
添加以下代码片段以填写注册表单并提交
此时,测试将填写注册表单并单击注册按钮。发生这种情况时,浏览器应重定向到主页,并且用户详细信息应在本地存储中以名为 'quoots-user'
的键提供。
添加以下内容以验证重定向是否发生以及用户数据是否在本地存储中可用
如果一切顺利,当您运行时,您应该看到第四组成功的测试

注意:请记住,在此测试期间创建的测试帐户在测试完成后会被清理掉。要验证这一点,请尝试在
e2e/tests/helpers/prisma.ts
中启用 查询日志记录,然后再次运行测试以查看清理查询。
验证用户在登录后是否定向到主页
最后一个测试与之前的测试类似,但是,它假设数据库中已有一个用户帐户可用。它将登录而不是创建新帐户,并验证用户最终是否进入主页。
因为您需要生成一个新帐户,而不仅仅是一组唯一的凭据,所以此测试应包含 account
fixture,而不是 user_credentials
fixture
此测试的指令集与之前的测试几乎相同,除了您将使用 account
对象的值而不是 user_credentials
值来填充登录表单
如果您现在运行测试套件,您应该看到第五组成功的测试

为什么选择 Playwright?
有很多工具可以帮助您编写和运行端到端测试。这些工具中的许多工具都非常成熟,并且在它们旨在完成的工作上做得很好。
那么...为什么本文使用 Playwright 这个相对较新的端到端测试工具,而不是更成熟的工具呢?
本文选择 Playwright 作为首选工具有几个原因
- 易于使用
- 可扩展的 API
- 灵活的 fixture 系统
在本文中,您编写的测试的一个重要方面是 fixture 的实现,它允许您设置特定于测试的数据并在之后清理该数据。
由于 Playwright 直观且可扩展的 fixture 系统,您能够直接在这些 fixture 中导入和使用 Prisma Client,以在数据库中创建和删除数据。
可扩展性和开发者体验是我们 Prisma 非常关心的方面。扩展 Playwright 及其 fixture 的简单直观的体验在决定工具时起到了重要作用。
注意:这并不是说任何其他工具“不好”。上面的观点只是表达了 Playwright 特别适合本文中提出的特定用例。
总结 & 接下来是什么
端到端测试使您能够自动化您原本必须手动进行的测试类型。通过一系列指令,您可以导航您的应用程序并确保所需的行为正常工作。
在整篇文章中,您
- 了解了什么是端到端测试
- 在 pnpm 中设置了一个项目来保存您的端到端测试
- 配置并编写了您的测试环境脚本
- 创建了 fixture 和 页面 以避免测试中的代码重复
- 编写了一组测试来验证您的应用程序的身份验证工作流程
本教程涵盖了很多内容!我们鼓励您查看 GitHub 存储库,以查看涵盖整个应用程序的完整端到端测试套件。
在本系列的下一篇也是最后一篇中,您将设置一个 CI/CD 管道,以便在您将更改推送到 GitHub 存储库时运行您的单元测试、集成测试和端到端测试。
不要错过下一篇文章!
注册 Prisma 新闻通讯