Prisma 測試終極指南：整合測試

目錄

• 目錄
• 引言
  • 什麼是整合測試？
  • 您將使用的技術
• 先決條件
  • 假定知識
  • 開發環境
• 在 Docker 容器中設定 Postgres
• 為整合測試新增 Vitest 配置檔案
• 更新單元測試配置
• 編寫指令碼以啟動測試環境
• 配置 npm 指令碼
• 編寫整合測試
  • 為 /auth/signup 編寫測試
  • 為 /auth/signin 編寫測試
• 總結與展望

引言

到目前為止，在本系列中，您已經探索瞭如何模擬 Prisma 客戶端，並使用該模擬的 Prisma 客戶端對應用程式中小型獨立區域編寫單元測試。

在本系列的這一部分中，您將告別模擬的 Prisma 客戶端，並針對真實的資料庫編寫整合測試！到本文結束時，您將設定好整合測試環境，併為您的 Express API 編寫整合測試。

什麼是整合測試？

在本系列的前一篇文章中，您學習了編寫單元測試，重點是測試小的獨立程式碼單元，以確保應用程式最小的構建塊正常執行。這些測試的目標是測試特定的場景和功能片段，而無需擔心底層資料庫、外部模組或元件之間的互動。

然而，整合測試則是一種完全不同的思維模式。這種測試涉及將應用程式中相關的區域或元件結合起來，並確保它們能夠正常協同工作。

上圖展示了一個示例場景：獲取使用者的帖子可能需要多次訪問資料庫，以驗證使用者是否具有訪問 API 或任何帖子的許可權，然後才能實際檢索資料。

如上所示，應用程式的多個元件可能參與處理單個請求或操作。這通常意味著在單個請求或呼叫期間，資料庫互動會在不同元件之間多次發生。因此，整合測試通常包含一個帶有資料庫的測試環境。

在對整合測試進行了簡要概述之後，您現在將開始準備執行整合測試的環境。

您將使用的技術

• Vitest
• Prisma
• Node.js
• Postgres
• Docker

先決條件

假定知識

在完成以下步驟時，具備以下知識會有所幫助

• JavaScript 或 TypeScript 的基礎知識
• Prisma Client 及其功能的基礎知識
• Docker 的基礎理解
• 一些測試框架的使用經驗

開發環境

要跟隨提供的示例，您需要具備以下條件

• 已安裝 Node.js
• 您選擇的程式碼編輯器（我們推薦 VSCode）
• 已安裝 Git
• 已安裝 Docker

本系列大量使用了這個 GitHub 倉庫。請確保克隆該倉庫並切換到 unit-tests 分支，因為該分支是本文的起點。

克隆倉庫

在您的終端中，進入您儲存專案的目錄。在該目錄中執行以下命令

上述命令會將專案克隆到名為 express_sample_app 的資料夾中。該倉庫的預設分支是 main，因此您需要切換到 unit-tests 分支。

克隆倉庫後，需要執行幾個步驟來設定專案。

首先，進入專案並安裝 node_modules

接下來，在專案的根目錄建立 .env 檔案

此檔案應包含一個名為 API_SECRET 的變數，其值可以設定為任何您想要的 string，以及一個名為 DATABASE_URL 的變數，目前可以留空。

在 .env 檔案中，API_SECRET 變數提供了一個秘鑰，用於認證服務加密您的密碼。在實際應用程式中，此值應替換為包含數字和字母的隨機長字串。

DATABASE_URL，顧名思義，包含您資料庫的 URL。您目前沒有或不需要一個真實的資料庫。

在 Docker 容器中設定 Postgres

準備測試環境的第一件事是使用 Docker Compose 構建一個 Docker 容器，該容器提供 Postgres 伺服器。這將是您的應用程式在執行整合測試時使用的資料庫。

然而，在繼續之前，請確保您的機器上已安裝並執行 Docker。您可以按照此處的步驟在您的機器上設定 Docker。

要開始配置您的 Docker 容器，請在專案根目錄建立一個名為 docker-compose.yml 的新檔案

該檔案將用於配置您的容器，讓 Docker 知道如何設定資料庫伺服器、使用哪個 映象（Docker 映象是一組詳細說明如何構建容器的指令），以及如何儲存容器的資料。

注意：您可以在 docker-compose.yml 檔案中配置大量內容。您可以在此處找到文件。

您的容器應建立並公開一個 Postgres 伺服器。

為此，首先指定您將使用的 Compose 檔案格式版本

此版本號還決定了您將使用的 Docker 引擎版本。3.8 是撰寫本文時的最新版本。

接下來，您將需要一個 service，您的資料庫伺服器將在此服務中執行。建立一個名為 db 的新 service，並配置如下

上面新增的配置指定了一個名為 db 的服務，具有以下配置

• image：定義構建此服務時使用的 Docker 映象
• restart：always 選項讓 Docker 知道在發生故障或 Docker 重啟時隨時重啟此服務
• environment：配置要在容器中公開的環境變數
• ports：指定 Docker 應將您機器的 5432 埠對映到容器的 5432 埠，Postgres 伺服器將在此埠執行
• volumes：指定卷的名稱以及容器將在本地機器上持久化其資料的位置

要完成服務的配置，您需要讓 Docker 知道如何配置 volumes 配置中定義的卷並將其聯網。

將以下內容新增到您的 docker-compose.yml 檔案中，讓 Docker 知道卷應儲存在您的本地 Docker 主機（檔案系統）上

如果您現在前往終端並導航到專案根目錄，您應該能夠執行以下命令來啟動執行 Postgres 的容器

您的資料庫伺服器現在可以透過 URL postgres://postgres:postgres@localhost:5432 訪問。

更新您的 .env 檔案的 DATABASE_URL 變數，使其指向該 URL 並將 quotes 指定為資料庫名稱

為整合測試新增 Vitest 配置檔案

在上一篇文章中，您為 Vitest 建立了一個配置檔案。vitest.config.unit.ts 這個配置檔案是專門用於專案中的單元測試的。

現在，您將建立第二個名為 vitest.config.integration.ts 的配置檔案，您將在其中配置 Vitest 在執行整合測試時應如何執行。

注意：在本系列中，這些檔案將非常相似。根據專案的複雜性，像這樣拆分配置會帶來更明顯的好處。

在專案根目錄建立一個名為 vitest.config.integration.ts 的新檔案

將以下內容貼上到該新檔案中

上面的程式碼片段與 vitest.config.unit.ts 的內容基本相同，只是 test.include blob 指向 src/tests 中的任何 .ts 檔案，而不是像單元測試配置那樣指向 src 中的任何檔案。這意味著您的所有整合測試都應放在 src 中一個名為 tests 的新資料夾中。

接下來，為此新配置檔案新增另一個鍵，告訴 Vitest 不要在不同的執行緒中同時執行多個測試

這極其重要，因為您的整合測試將與資料庫互動並期望特定的資料集。如果多個測試同時執行並與您的資料庫互動，您可能會因為意外資料而在測試中導致問題。

類似地，您還需要一種在測試之間重置資料庫的方法。在此應用程式中，您將在每次測試之間完全清除資料庫，以便每次測試都可以從一個空白狀態開始。

在 src 中建立一個名為 tests 的新資料夾，並在 tests 中建立一個名為 helpers 的新資料夾

在該新目錄中，建立一個名為 prisma.ts 的檔案

此檔案是一個輔助檔案，它僅例項化並匯出 Prisma Client。

將以下內容新增到該檔案中

現在在 src/tests/helpers 中建立另一個名為 reset-db.ts 的檔案

此檔案將用於編寫和匯出重置資料庫的函式。

您的資料庫只有三個表：Tag、Quote 和 User。編寫並匯出一個函式，該函式在事務中對這些表中的每一個執行 deleteMany

透過上面編寫的檔案，您現在有了一種清除資料庫的方法。這裡要做的最後一件事是在每個整合測試之間實際呼叫該函式。

一個好方法是使用設定檔案。這是一個您可以配置 Vitest 在執行任何測試之前處理的檔案。您可以在這裡使用 Vitest 的生命週期鉤子來自定義其行為。

在 src/tests/helpers 中建立另一個名為 setup.ts 的檔案。

您的目標是在每個測試之前重置資料庫，以確保您有一個乾淨的環境。您可以透過在 Vitest 提供的 beforeEach 生命週期函式中執行 reset-db.ts 匯出的函式來實現此目的。

在 setup.ts 中，使用 beforeEach 在每個測試之間執行您的重置函式

現在，當您執行測試套件時，src/tests 中所有檔案中的每個獨立測試都將從一個乾淨的狀態開始。

注意：您可能想知道在特定測試上下文中，您希望從一些資料開始的場景。在您編寫的每個單獨測試檔案中，您還可以利用這些生命週期函式並按檔案自定義行為。稍後將展示一個示例。

最後，您現在需要讓 Vitest 知道這個設定檔案，並告訴它在您執行測試時執行該檔案。

使用以下內容更新 vitest.config.integration.ts

更新單元測試配置

目前，單元測試配置檔案也會執行您的整合測試，因為它會搜尋 src 中包含的任何 .ts 檔案。

更新 vitest.config.unit.ts 中的配置，以忽略 src/tests 中的檔案

現在，您的單元測試和整合測試完全分離，只能使用各自的獨立命令執行。

編寫指令碼以啟動測試環境

到目前為止，您已經構建了以下方法

• 在 Docker 容器中啟動資料庫伺服器
• 使用特定測試配置執行整合測試
• 將單元測試與整合測試分開執行

缺少的是一種實際協調 Docker 容器的建立和整合測試執行的方法，以確保您的資料庫正在執行並可用於您的測試環境。

為了實現這一點，您將編寫一組自定義 bash 指令碼，用於啟動 Docker 容器，等待伺服器準備就緒，然後執行測試。

在專案根目錄建立一個名為 scripts 的新目錄

在該目錄中，建立一個名為 run-integration.sh 的檔案

在此檔案中，您需要完成以下步驟

1. 從 .env 載入所有環境變數，以便您可以訪問資料庫 URL。
2. 以分離模式啟動 Docker 容器。
3. 等待資料庫伺服器可用。
4. 執行 Prisma 遷移，將您的 Prisma schema 應用到資料庫。
5. 執行您的整合測試。作為額外福利，您還應該能夠使用 --ui 標誌執行此檔案，以啟動 Vitest 的 GUI 介面。

載入環境變數

第一步是讀取 .env 檔案，並在指令碼上下文中使這些變數可用。

在 scripts 中建立另一個名為 setenv.sh 的檔案

在此檔案中，新增以下程式碼片段

這將讀取您的 .env 檔案並匯出每個變數，使其在您的指令碼中可用。

回到 scripts/run-integration.sh，您現在可以使用此檔案透過 source 命令訪問環境變數

上面，DIR 變數用於查詢 setenv.sh 的相對路徑，並使用該路徑執行指令碼。

以分離模式啟動 Docker 容器

下一步是啟動您的 Docker 容器。重要的是要注意，您需要以分離模式啟動容器。

通常，當您執行 docker-compose up 時，您的終端將連線到容器的輸出，以便您可以看到正在發生的情況。但是，這會阻止終端執行任何其他操作，直到您停止 Docker 容器。

以分離模式執行容器允許它在後臺執行，從而解放您的終端以繼續執行命令（例如執行整合測試的命令）。

將以下內容新增到 run-integration.sh

這裡，-d 標誌表示容器應以分離模式執行。

使指令碼等待資料庫伺服器準備就緒

在執行 Prisma 遷移和測試之前，您需要確保資料庫已準備好接受請求。

為了做到這一點，您將使用一個著名的指令碼，名為 wait-for-it.sh。該指令碼允許您提供一個 URL 和一些時間配置，並會使指令碼等待直到所提供 URL 處的資源可用後再繼續執行。

透過執行以下命令，將該指令碼的內容下載到名為 scripts/wait-for-it.sh 的檔案中

警告：如果 wait-for-it.sh 指令碼對您不起作用，請參閱 GitHub 討論以獲取連線資料庫並確保測試成功執行的替代方法。

然後，回到 run-integration.sh 並使用以下內容進行更新

您的指令碼現在將等待 DATABASE_URL 環境變數中指定的資料庫位置可用後，再繼續執行。

如果您使用的是 Mac，您還需要執行以下命令來安裝和別名 wait-for-it.sh 指令碼中使用的命令

準備資料庫並執行測試

最後兩個步驟現在可以安全地執行了。

在執行 wait-for-it 指令碼後，執行 Prisma 遷移以將任何新更改應用到資料庫

最後，新增以下語句來執行您的整合測試

請注意使用的 if/else 語句。這允許您查詢傳遞給指令碼的標誌。如果找到標誌，則假定為 --ui，並將使用 Vitest 使用者介面執行測試。

使指令碼可執行

執行測試所需的指令碼都已完成，但是如果您嘗試執行其中任何一個，您將遇到許可權錯誤。

為了使這些指令碼可執行，您需要執行以下命令，這將授予您當前使用者執行它們的許可權

配置 npm 指令碼

您的指令碼現在是可執行的。下一步是在 package.json 中建立 scripts 記錄，這些記錄將呼叫這些自定義指令碼並啟動您的測試。

在 package.json 中，將以下內容新增到 scripts 部分

現在，如果您執行以下任何一個指令碼，您應該會看到 Docker 容器正在啟動，Prisma 遷移正在執行，最後您的測試正在執行

注意：目前您的測試將失敗。這是因為 Vitest 找不到任何包含測試的檔案。

編寫整合測試

現在是時候利用您的測試環境並編寫一些測試了！

在考慮應用程式的哪些部分需要整合測試時，重要的是要考慮元件之間重要的互動以及這些互動是如何被呼叫的。

就您正在使用的 Express API 而言，重要的互動分組發生在路由、控制器和服務之間。當用戶訪問 API 中的一個端點時，路由處理器會將請求傳遞給控制器，控制器可能會呼叫服務函式來與資料庫互動。

考慮到這一點，您的整合測試將專注於單獨測試每個路由，確保每個路由都能正確響應 HTTP 請求。這包括對 API 的有效和無效請求。目標是讓您的測試模仿 API 消費者在與 API 互動時的體驗。

注意：關於整合測試應涵蓋哪些內容，存在許多不同的意見。在某些情況下，開發人員可能希望編寫專門的整合測試，以確保較小的元件（例如您的控制器和服務）能夠正確協同工作，同時編寫驗證整個 API 路由是否正常工作的測試。關於測試中應涵蓋哪些內容的決定完全取決於您應用程式的需求以及作為開發人員您認為需要測試的內容。

與本系列之前的文章類似，為了使本教程的資訊長度可控，您將專注於為 API 路由 /auth/signin 和 /auth/signup 編寫測試。

注意：如果您對 /quotes/* 路由的測試樣式感興趣，完整的測試集可在 GitHub 倉庫的 integration-tests 分支中找到。

為 /auth/signup 編寫測試

在 src/tests 中建立一個名為 auth.test.ts 的新檔案

這裡將存放與 API 的 /auth 路由相關的所有測試。

在此檔案中，從 Vitest 匯入 describe、expect 和 it 函式，並使用 describe 定義此測試套件

您將測試的第一個端點是 POST /auth/signup 路由。

在測試套件上下文中，新增另一個 describe 塊來描述與此特定路由關聯的測試套件

此路由允許您提供使用者名稱和密碼來建立新使用者。透過檢視 src/auth/auth.controller.ts 中的邏輯和 src/auth/auth.routes.ts 中的路由定義，可以確定以下需要測試的重要行為

• 它應該以 200 狀態碼和使用者詳情響應
• 成功時應響應有效的會話令牌
• 如果存在使用所提供使用者名稱的使用者，它應以 400 狀態碼響應
• 如果提供了無效的請求體，它應以 400 狀態碼響應

注意：測試應包括您期望從 API 獲得的所有不同響應，無論是成功還是錯誤。通常，閱讀 API 的路由定義和控制器就足以確定您應該測試的不同場景。

接下來的四個部分將詳細介紹如何為這些場景編寫測試。

它應該以 200 狀態碼和使用者詳情響應

為了開始編寫此場景的測試，請使用從 Vitest 匯入的 it 函式來描述“它”應該做什麼。

在 /auth/signup 路由的 describe 塊中新增以下內容

為了實際嚮應用程式中的端點 POST 資料，您將使用一個名為 supertest 的庫。此庫允許您向其提供一個 HTTP 伺服器，並透過簡單的 API 向該伺服器傳送請求。

將 supertest 安裝為開發依賴

然後將 supertest 匯入到 src/tests/auth.test.ts 的頂部，命名為 request。同時匯入 src/lib/createServer 的預設匯出，它提供了 app 物件

您現在可以使用 request 函式向您的 Express API 傳送請求

上面，app 例項被傳遞給 request 函式。該函式的響應是一組函式，允許您與傳遞給 request 的 HTTP 伺服器進行互動。

然後使用 post 函式定義您要互動的 HTTP 方法和路由。最後呼叫 send 傳送 POST 請求以及請求體。

返回的值包含請求響應的所有詳細資訊，但 status 和 body 值是從響應中特別提取出來的。

現在您已獲得響應狀態和正文，您可以驗證路由是否執行了預期操作並以正確的值響應。

將以下內容新增到此測試中以驗證這些情況

以上更改執行以下操作

1. 匯入 prisma，以便您可以查詢資料庫以再次檢查資料是否正確建立
2. 使用 prisma 獲取新建立的使用者
3. 確保請求以 200 狀態碼響應
4. 確保找到了使用者記錄
5. 確保響應體包含一個 user 物件，其中包含使用者的 username 和 id

如果您在終端中執行 npm run test:int:ui，您應該會看到 Vitest GUI 開啟，並顯示成功的測試訊息。

注意：如果您尚未執行此命令，系統可能會提示您安裝 @vitest/ui 包並重新執行該命令。

注意：在此測試中，沒有模擬任何模組，包括 Prisma Client！您的測試針對真實資料庫執行，並驗證了此路由中的資料互動是否正常工作。

成功時應響應有效的會話令牌

接下來的測試將驗證，當建立使用者時，響應中應包含一個會話令牌，該令牌可用於驗證該使用者對 API 的請求。

在前一個測試下方為該場景建立一個新測試

此測試將比前一個簡單一些。它只需要傳送一個有效的註冊請求並檢查響應，以驗證是否返回了有效的令牌。

使用 supertest 向 /auth/signup 端點發送 POST 請求並獲取響應體

響應體應包含一個名為 token 的欄位，其中包含會話令牌字串。

新增一組斷言，驗證響應中是否存在 token 欄位，並使用 jwt 庫驗證該令牌是否是有效的會話令牌

如果存在使用所提供使用者名稱的使用者，它應以 400 狀態碼響應

到目前為止，您已經驗證了對 /auth/signup 的有效請求按預期響應。現在您將轉換思路，確保應用程式適當地處理無效請求。

為此場景新增另一個測試

為了觸發當使用現有使用者名稱發出註冊請求時應發生的 400 錯誤，資料庫中必須已經存在一個使用者。

為此測試新增一個查詢，建立一個名為 'testusername' 的使用者，並使用任意密碼

現在，您應該能夠透過傳送與該使用者同名的註冊請求來觸發錯誤。

注意：請記住，此使用者記錄（以及由於您的註冊測試而建立的其他記錄）會在每個單獨的測試之間刪除。

向 /auth/signup 傳送請求，提供與上面建立的使用者相同的使用者名稱：'testusername'

現在請求已傳送到該端點，是時候考慮在這種情況下您會期望發生什麼了。您會期望

• 請求以 400 狀態碼響應
• 響應體不包含 user 物件
• 資料庫中的使用者數量僅為 1

向測試新增以下斷言，以驗證所有這些點都已滿足

如果提供了無效的請求體，它應以 400 狀態碼響應

您將為該端點編寫的最後一個測試是驗證如果向 API 傳送無效請求體，請求將以 400 狀態碼響應。

此端點，如 src/auth/auth.router.ts 中所示，使用 zod 透過在 src/lib/middlewares.ts 中定義的名為 validate 的中介軟體來驗證其請求體是否包含有效的 username 和 password 欄位。

此測試將專門確保 validate 中介軟體和 zod 定義按預期工作。

為此場景新增新測試

此測試將非常簡單。它只需向 /auth/signup 端點發送一個 POST 請求並提供一個無效的請求體。

使用 supertest 向 /auth/signup 傳送 POST 請求，但不是傳送 username 欄位，而是傳送 email 欄位

此請求體應導致驗證中介軟體在繼續到控制器之前以 400 錯誤程式碼響應請求。

使用以下一組斷言來驗證此行為

至此，您為 /auth/signup 端點編寫的測試套件已完成！如果您回到 Vitest GUI，您應該會看到所有測試都已成功透過

為 /auth/signin 編寫測試

您將編寫測試的下一個端點與上一個有很多相似之處，但它不是建立新使用者，而是驗證現有使用者。

/auth/signin 端點接收 username 和 password，確保存在一個具有所提供資料的使用者，生成一個會話令牌，並以會話令牌和使用者詳情響應請求。

注意：此功能的實現可以在 src/auth/auth.controller.ts 和 src/auth/auth.router.ts 中找到。

在您的測試套件中，您將驗證此端點具有以下特性

• 提供有效憑據時，它應以 200 狀態碼響應
• 成功時應響應使用者詳情
• 成功時應響應有效的會話令牌
• 提供無效憑據時，它應以 400 狀態碼響應
• 找不到使用者時，它應以 400 狀態碼響應
• 提供無效請求體時，它應以 400 狀態碼響應

在測試每個場景之前，您需要定義另一個測試套件，以將所有與此端點相關的測試分組。

在定義 /auth/signup 測試套件的結束標籤下，為 /auth/signin 路由新增另一個 describe

您在此套件中編寫的測試也需要資料庫中存在一個使用者，因為您將測試登入功能。

在您剛剛新增的 describe 塊中，您可以使用 Vitest 的 beforeEach 函式在每個測試之前向資料庫新增一個使用者。

將以下內容新增到新的測試套件中

注意：重要的是，此處的密碼加密方法必須與 src/auth/auth.service.ts 中使用的加密方法完全匹配。

現在，此測試套件的初始設定已完成，您可以繼續編寫測試。

和之前一樣，接下來的六個部分將分別涵蓋這些場景，並詳細說明測試的工作原理。

提供有效憑據時，它應以 200 狀態碼響應

第一個測試將簡單地驗證，使用正確憑據的有效登入請求是否會從 API 獲得 200 響應碼。

首先，將您的新測試新增到此測試套件的 describe 塊中，緊跟在 beforeEach 函式下方

為了測試所需行為，向 /auth/signin 端點發送一個 POST 請求，其中包含用於建立測試使用者的相同使用者名稱和密碼。然後驗證響應的狀態碼是否為 200

成功時應響應使用者詳情

下一個測試與前一個測試非常相似，但不是檢查 200 響應狀態，而是檢查響應體中的 user 物件並驗證其內容。

新增另一個測試，內容如下

以上測試內容執行以下操作

1. 向 /auth/signin 傳送一個 POST 請求，請求體中包含測試使用者的使用者名稱和密碼
2. 提取響應體中 user 物件的鍵
3. 驗證響應中存在兩個鍵：id 和 username，並且 user.username 的值與測試使用者的使用者名稱匹配

成功時應響應有效的會話令牌

在此測試中，您將再次遵循與前兩個測試非常相似的過程，只是此測試將驗證響應體中是否存在有效的會話令牌。

在前一個測試下方新增以下測試

如您所見，請求已傳送到目標端點，並且響應體已從結果中提取出來。

使用 toHaveProperty 函式驗證響應體中是否存在 token 鍵。然後使用 jwt.verify 函式驗證會話令牌。

注意：重要的是，與密碼加密類似，會話令牌的驗證必須使用與 src/auth/auth.service.ts 中使用的函式相同的函式。

提供無效憑據時，它應以 400 狀態碼響應

您現在將驗證傳送帶有無效憑據的請求體是否會導致正確的錯誤響應。

為了重現此場景，您只需向 /auth/signin 傳送一個 POST 請求，其中包含測試使用者正確的使用者名稱但密碼不正確。

新增以下測試

如您所見，響應的狀態碼預計為 400。

還添加了一個預期，即響應體不應包含 token 屬性，因為無效的登入請求不應觸發會話令牌的生成。

注意：此測試的第二個預期並非嚴格必要，因為 400 狀態碼足以說明控制器中的條件已滿足，從而短路請求並響應錯誤。

找不到使用者時，它應以 400 狀態碼響應

在這裡，您將測試找不到具有所提供使用者名稱的場景。與之前的測試情況一樣，這應該會短路請求並導致以錯誤狀態碼提前響應。

將以下內容新增到您的測試中

提供無效請求體時，它應以 400 狀態碼響應

在此最終測試中，您將驗證傳送無效請求體是否會導致錯誤響應。

在 src/auth/auth.router.ts 中使用的 validate 中介軟體應該捕獲無效的請求體並完全短路身份驗證控制器。

新增以下測試來完成此測試套件

如您所見，username 欄位被替換為 email 欄位，就像本文前面測試中所做的那樣。因此，請求體與請求體的 zod 定義不匹配，並觸發錯誤。

如果您前往 Vitest GUI，您應該會看到兩個端點的整個測試套件都成功通過了所有檢查。

總結與展望

恭喜您讀完本文！測試系列的這一部分資訊量非常大，讓我們回顧一下。在本文中，您

• 瞭解了什麼是整合測試
• 設定了一個 Docker 容器，用於在您的測試環境中執行 Postgres 資料庫
• 配置了 Vitest，以便您可以獨立執行單元測試和整合測試
• 編寫了一組啟動 shell 指令碼，以啟動您的測試環境並執行您的整合測試套件
• 為您的 Express API 中的兩個主要端點編寫了測試

在本系列的下一部分中，您將瞭解本文將涵蓋的最後一種測試：端到端測試。

我們希望您能繼續關注本系列的其餘部分！