使用 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 賬戶，可以在此處免費建立一個。

登入後，點選下方所示的新建按鈕以建立新倉庫

在下一頁，您將被要求提供一些關於您的倉庫的資訊。填寫下方指示的欄位，然後點選頁面底部的建立倉庫按鈕

然後您將被導航到新倉庫的主頁。在頂部會有一個文字欄位，允許您複製倉庫的 URL。點選複製圖示以複製 URL。

現在您已經獲得了新 GitHub 倉庫的 URL，在終端中進入程式碼庫的根目錄，並使用以下命令將專案來源指向新倉庫（請務必在第二行插入您剛剛複製的 URL）

您將基於 e2e-tests 分支的進度進行工作，因此該分支應被視為 main。將 e2e-tests 合併到 main 中

最後，將專案推送到您的新倉庫

設定工作流

您現在已經設定好了一個可以推送更改的倉庫。下一個目標是當對您已建立的 main 分支進行或更新拉取請求時，觸發一系列任務。

在使用 GitHub 時，您可以建立工作流檔案來定義這些步驟。這些檔案必須建立在專案根目錄下的 .github/workflows 資料夾中。

在您的專案中建立一個名為 .github 的新資料夾

在 .github/workflows 資料夾中，建立一個名為 test.yml 的新檔案，您將在其中定義測試工作流。

在該檔案中，您將提供 GitHub Actions 準備專案並執行測試套件的步驟。

要啟動此工作流，請使用 name 屬性為您的工作流命名

該工作流現在將在 GitHub 中顯示為 'Tests'。

接下來要做的是配置此工作流，使其僅在對倉庫的 main 分支發出拉取請求時執行。新增帶有以下選項的 on 關鍵字來實現此目的

注意：請注意縮排。縮排在 YAML 檔案中非常重要，不正確的縮排會導致檔案失敗。

現在您已經命名了工作流，並配置它僅在對 main 進行拉取請求或更新時執行。接下來，您將開始定義一個執行單元測試的任務。

注意：工作流檔案中可以配置的選項非常多，它們會改變工作流的執行方式、功能等等……要檢視完整列表，請查閱 GitHub 的文件。

新增單元測試任務

為了定義與特定任務（稱為步驟）相關的一組指令，您將使用 job 關鍵字。每個任務都在您配置的獨立環境中執行其一系列步驟。

在 .github/workflows/tests.yml 檔案中新增一個 jobs 部分，並指定一個名為 unit-tests 的任務

如前所述，每個獨立的任務都在其自己的環境中執行。為了執行一個任務，您需要指定任務應該在哪種型別的機器上執行。

使用 runs-on 關鍵字指定任務應在 ubuntu-latest 機器上執行

您將定義的最後一個部分是 steps 部分，您將在此定義任務執行單元測試所需的一系列步驟。

將以下內容新增到 unit-tests 任務中

這定義了一個包含一個步驟的 steps 部分。該步驟使用預構建操作 v3 的 actions/checkout，它會檢出您的 GitHub 倉庫，以便您可以在任務內部與它互動。

注意：一個action是您可以在工作流中使用的單個步驟的集合。它們有助於將可重用的一系列步驟分解到一個檔案中。

接下來，您需要定義一組步驟，用於在虛擬環境中安裝 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 分支中。

在瀏覽器中前往倉庫。在頁面頂部的拉取請求選項卡中，您應該看到一個比較並拉取請求按鈕，因為 new-branch 最近有推送

點選該按鈕以開啟拉取請求。您應該會被導航到一個新頁面。在該新頁面上，點選建立拉取請求按鈕以開啟拉取請求。

開啟拉取請求後，您應該會在合併拉取請求按鈕上方看到一個黃色框，顯示您的測試任務正在執行

如果您點選詳情按鈕，您應該會看到每個步驟的執行情況及其控制檯輸出。

一旦任務完成，您將收到工作流中的檢查是否透過的通知

現在您的單元測試任務已完成，您將繼續建立執行整合測試的任務。

注意：暫不要合併此拉取請求！您將在本文的其餘部分重複使用此拉取請求。

新增整合測試任務

執行整合測試的過程與執行單元測試非常相似。此任務的區別在於，您的整合測試依賴於測試資料庫和環境變數。在本節中，您將設定這些並定義一個任務來執行您的測試。

在開始進行更改之前，您需要再次檢出倉庫的 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 的步驟之後，立即新增兩個新步驟，用於下載 Playwright 並將其測試瀏覽器安裝到專案的 e2e 資料夾中。

您還需要在 env 部分新增兩個新的環境變數，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 與我聯絡。