端到端測試是應用程式測試中一種更“宏觀”的形式，它允許您從使用者的角度測試與應用程式的互動。本文中，您將看到設定和編寫端到端測試的一些實際示例。
目錄
引言
在本系列的此時，您已經編寫了大量的測試，以確保獨立的 Express API 的功能和行為按預期工作。這些測試以整合測試和單元測試的形式出現。
在本系列的這一部分中，您將為該應用程式新增另一層複雜性。本文將探討一個包含與之前文章中相同的 Express API 和測試以及一個使用該 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 單體倉庫，包含兩個獨立的應用程式。
以下是專案的資料夾結構：
backend 資料夾包含 Express API 及其整合測試和單元測試。該專案與本系列前幾節中使用的 API 相同。
frontend 資料夾包含一個新的前端 React 應用程式。該應用程式已完成，不會在本系列中修改。
prisma 和 scripts 資料夾包含與本系列前幾篇文章中相同的檔案。prisma/ 包含 schema.prisma 檔案，scripts/ 包含幫助執行和設定測試環境的 .sh 指令碼。
其餘檔案定義了包配置、Docker 容器和 pnpm 工作區。
如果您檢視 package.json，您會在 scripts 部分看到以下內容：
這些是在 pnpm 單體倉庫中可以執行的命令。這裡的命令主要使用 pnpm 執行在 backend/package.json 和 frontend/package.json 中定義的命令。
從專案根目錄執行以下命令以啟動應用程式：
如果您隨後導航到 http//:5173，您應該會看到應用程式的登入頁面
接下來，您將開始設定您的端到端測試及其測試環境。
為端到端測試設定專案
為了開始設定端到端測試，您將在您的單體倉庫中設定一個新專案，該專案將包含所有您的端到端測試程式碼。
注意：您的端到端測試及其相關程式碼位於單體倉庫中的一個獨立專案中，因為這些測試不屬於前端或後端專案。它們是獨立的實體，並與這兩個專案互動。
此過程的第一步是為您的專案建立一個新資料夾。
在單體倉庫的根目錄新增一個名為 e2e 的新資料夾
在該新目錄中，您需要使用以下命令初始化 pnpm
此命令將建立一個 package.json 檔案，其中包含初始配置，包括一個名為 'e2e' 的 name 欄位。pnpm 將使用此名稱來定義專案的工作區。
在單體倉庫的根目錄中，開啟 pnpm-workspace.yaml 檔案並新增以下內容：
您將編寫端到端測試的專案現在已在您的 pnpm 單體倉庫中註冊，您可以開始設定您的測試庫了。
安裝並初始化 Playwright
本文中，您將使用 Playwright 執行您的端到端測試。
注意：為什麼是 Playwright 而不是 Cypress 或其他更成熟的工具？本文稍後將重點介紹 Playwright 的一些非常酷的功能，這些功能使 Playwright 在此特定用例中脫穎而出。
首先，在 e2e 目錄中安裝 playwright
執行上述命令後，系統會詢問您一系列有關專案的問題。透過點選 Enter 鍵使用每個選項的預設設定
請注意，選擇的選項是 '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 中執行命令的資訊，請查閱其文件。
每個物件都將 reuseExistingServer 鍵設定為 true。這使得 Playwright 知道，如果伺服器在執行測試之前已經啟動，則應重用它。
編寫啟動指令碼
現在 Playwright 本身已配置為啟動開發伺服器，您還需要一種方法，透過一個命令同時啟動測試資料庫和 Playwright 的測試執行器。
您將執行此操作的方式與本系列上一篇文章中編寫的指令碼非常相似，該指令碼用於在執行整合測試之前啟動資料庫。
進入單體倉庫根目錄的 scripts/ 資料夾，建立一個名為 run-e2e.sh 的新檔案
該檔案是您將編寫啟動指令碼的地方。
注意：檢視
scripts/run-integration.sh以瞭解上一篇文章中編寫的啟動指令碼。
該檔案首先需要設定為可執行檔案，這將允許您透過終端執行該檔案。
將以下內容新增到 run-e2e.sh 檔案的最頂部：
注意：此行被稱為 shebang 行，用於將 bash 設定為執行命令的預設 shell。
然後，從單體倉庫的根目錄執行以下命令，將該檔案標記為檔案系統中的可執行檔案：
現在檔案是可執行的了，您將開始編寫實際的啟動指令碼。
新增以下行以執行本系列上一篇文章中編寫的資料庫啟動指令碼：
此指令碼將根據專案根目錄的 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 schema 的位置
這允許您在終端導航到 e2e 資料夾時執行端到端測試。
為了使其更簡單，請前往單體倉庫根目錄的 package.json 檔案，並在 scripts 部分新增以下內容：
現在您可以從專案的根目錄執行端到端測試了。
假設您的終端當前位於 e2e 資料夾中，以下命令將導航您到專案根目錄並執行您的測試指令碼
測試報告應該為空。因為沒有測試！
編寫端到端測試
Playwright 已配置完畢，您的測試環境已準備就緒！您現在將開始為應用程式編寫端到端測試。
測試什麼
在本文中，您將為應用程式中所有與認證工作流相關的部分編寫端到端測試。
注意：GitHub 倉庫的
e2e-tests分支包含針對整個應用程式的完整端到端測試套件。
請記住，端到端測試側重於測試使用者可能操作的應用程式工作流。看看您將要編寫測試的登入頁面：
儘管可能並非立即顯而易見，但您可以測試使用者在認證方面可能遇到的許多場景。
例如，使用者應該：
- ... 如果未登入時嘗試訪問主頁，則應被重定向到登入頁面。
- ... 成功建立帳戶後，應被重定向到主頁。
- ... 成功登入後，應被重定向到主頁。
- ... 如果登入嘗試不成功，應收到警告。
- ... 如果嘗試使用現有使用者名稱註冊，應收到警告。
- ... 如果提交空表單，應收到警告。
- ... 退出登入後，應返回到登入頁面。
在本文中，您將僅為其中幾個場景編寫測試，以保持篇幅可控。具體來說，本文將涵蓋以下場景。
使用者應該：
- ... 如果未登入時嘗試訪問主頁，則應被重定向到登入頁面。
- ... 成功建立帳戶後，應被重定向到主頁。
- ... 成功登入後，應被重定向到主頁。
- ... 如果登入嘗試不成功，應收到警告。
- ... 如果提交空表單，應收到警告。
注意：這些場景將涵蓋我們希望在本文中傳達的所有主要概念。我們也鼓勵您嘗試自己為其他場景編寫測試！
目標已明確，您現在將開始編寫測試。
示例測試
Playwright 提供了一個龐大的輔助工具和實用程式庫，讓您可以非常直觀地測試您的應用程式。
檢視下面為一個假設的允許您向公告板釋出訊息的應用程式的示例測試：
上述測試驗證了當您釋出訊息時，它會自動顯示在網頁上。
為了實現這一點，測試必須遵循使用者為達到預期結果所採取的流程。更具體地說，測試必須：
- 使用測試帳戶登入
- 提交帖子
- 驗證帖子是否顯示在網頁上
您可能已經注意到，許多這些步驟，例如登入，最終可能會被大量重複。特別是在一個包含數十個（或更多）需要登入使用者的測試套件中。
為了避免在每個測試中重複指令集，您將利用兩個概念，它們允許您將這些指令分組為可重用的塊。它們是頁面物件和夾具。
頁面物件
首先，您將為您的登入頁面設定一個頁面物件。這本質上只是一個輔助類，它將與網頁的各種互動分組到類的各個成員函式中，這些函式最終將由夾具和您的測試本身使用。
在 e2e/tests 資料夾中建立一個名為 pages 的新資料夾
在該資料夾內，建立一個名為 login.page.ts 的新檔案
在這裡，您將定義描述您的登入頁面的類。
在檔案的最頂部，匯入 Playwright 提供的 Page 型別
這個輔助型別描述了一個 Playwright 中所有註冊測試可用的名為 page 的夾具。page 物件表示瀏覽器中的一個單一標籤頁。您正在編寫的類將在其建構函式中需要這個 page 物件，以便它可以與瀏覽器頁面互動。
在 login.page.ts 中，新增並匯出名為 LoginPage 的類，其建構函式接受一個 Page 型別的 page 引數
有了瀏覽器頁面的訪問許可權，您現在可以定義此頁面特有的可重用互動。
首先，新增一個名為 goto 的成員函式，該函式導航到應用程式的 /login 頁面
注意：有關
page物件可用函式的資訊，請查閱 Playwright 的文件。
接下來，新增第二個函式來填寫登入表單
對於本教程，這些是登入頁面唯一需要的可重用指令集。
接下來，您將使用一個夾具來向每個測試公開此 LoginPage 類的例項。
夾具
回想一下上面顯示的示例測試：
在這裡，page 物件從 test 函式回撥函式的引數中解構出來。這與上一節中引用的 Playwright 提供的夾具相同。
Playwright 提供了一個 API，允許您擴充套件現有的 test 函式以提供自定義夾具。在本節中，您將編寫一個夾具，允許您向每個測試提供 LoginPage 類。
登入頁面夾具
從單體倉庫的根目錄開始，在 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 中，在匯入語句下方新增一個名為 UserDetails 的 type，其中包含 username 和 password 屬性
在 AuthFixtures 型別中使用此型別來描述一個新的 user_credentials 屬性
您的 test 物件現在可以處理 user_credentials 夾具。此夾具將執行三件事：
- 生成隨機使用者名稱和密碼
- 為每個測試提供包含使用者名稱和密碼的物件
- 使用 Prisma 刪除資料庫中所有具有生成使用者名稱的使用者
該夾具將使用 Faker 生成隨機資料，因此您首先需要在 e2e 資料夾中安裝 Faker 庫
此夾具中生成的憑據通常會用於透過 UI 建立新帳戶。為了避免在測試資料庫中留下陳舊資料，您需要一種方法在測試之間清理這些帳戶。
Playwright 的酷炫之處在於它執行在 Node 執行時中，這意味著您可以在測試和夾具中使用 Prisma Client 與資料庫互動。您將利用這一點來清理測試帳戶。
在 e2e/tests 資料夾中建立一個名為 helpers 的新資料夾，並新增一個名為 prisma.ts 的檔案。導航回單體倉庫的根目錄並執行以下命令：
在新檔案中，匯入 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 檔案中：
在此類中，新增一個單獨的getter 函式，該函式使用 context 夾具的 storageState 函式來訪問執行在 https://:5173 上的站點的瀏覽器上下文的本地儲存資料
注意：請查閱 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 函式點選登入按鈕，等待請求完成並驗證彈出窗口出現
現在執行端到端測試應該會顯示另一組成功的測試
驗證使用者嘗試提交空表單時是否收到警告
此測試與之前的測試非常相似，它將從登入頁面開始並提交登入表單。唯一的區別是表單應該為空，並且錯誤訊息應該包含文字：'請輸入使用者名稱和密碼'。
新增以下測試以驗證是否顯示預期錯誤訊息：
注意：在此測試中，
click函式透過loginPage.page屬性訪問。這純粹是為了消除變數未使用時出現的 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
- 靈活的夾具系統
在本文中，您編寫的測試的一個重要方面是夾具的實現，它允許您設定特定於測試的資料並在之後清理該資料。
由於 Playwright 直觀且可擴充套件的夾具系統，您可以直接在這些夾具中匯入和使用 Prisma Client 來在資料庫中建立和刪除資料。
擴充套件性和開發者體驗是我們在 Prisma 非常重視的。擴充套件 Playwright 及其夾具的簡單直觀體驗在決定工具時發揮了重要作用。
注意：這並非說其他工具“不好”。上述觀點僅僅表達了 Playwright 在本文所呈現的特定用例中表現得特別出色。
總結與下一步
端到端測試讓您能夠自動化原本需要手動完成的測試。透過一系列指令，您可以導航您的應用程式並確保預期行為正常工作。
在本文中，您：
- 瞭解了什麼是端到端測試
- 在 pnpm 中設定了一個專案來存放您的端到端測試
- 配置並編寫了測試環境指令碼
- 建立了夾具和頁面物件以避免測試中的程式碼重複
- 編寫了一組測試來驗證您的應用程式的認證工作流
本教程內容豐富！我們鼓勵您檢視 GitHub 倉庫，以檢視涵蓋整個應用程式的完整端到端測試套件。
在本系列的下一部分也是最後一部分中，您將設定一個 CI/CD 流水線，在您將更改推送到 GitHub 倉庫時執行您的單元測試、整合測試和端到端測試。
不要錯過下一篇文章！
訂閱 Prisma 簡報