在 GitHub 上為《SciFi-Tower》專案搭建 Unit Test、Integration Test 的 CI/CD 自動化流程（for Windows）

面對多人開發的專案，維護程式碼品質是一項挑戰，所以我在自己的專案《Sci-Fi Tower》上寫了部分測試，並把測試流程整合進 Github 的 CI/CD 中，這樣其他開發者上傳更動發布合併請求（pull request）時，大家都可以看到新更動是否通過測試，幫助大家判斷是否同意更動。

但我發現針對 Windows 環境的 Unity 整合文章非常少，網路上都是針對 Ubuntu 的，所以自己研究了幾天，終於能順利運行，想說分享給大家，如果大家專案有 DevOps 的需求可以參考。

名詞解釋

DevOps：「軟體開發人員（Dev）」和「IT 運維技術人員（Ops）」之間溝通合作的文化，通過自動化「軟體交付」和「架構變更」的流程，使得構建、測試、發布軟體更快捷、頻繁和可靠。
CI/CD：當開發者上傳更動到 Git 或是提交合併請求時，會觸發客製化的工作流程，以達到自動化測試/部屬
Unit Test：測試程式碼中的類別或函數是否如預期執行
Integration Test：專注於組件間的耦合，測試是否如預期運行

如何在 Unity 上編寫測試？

撰寫測試可提早發現問題，減少除錯時間，Unity 有提供 Unity Test Runner 給開發者撰寫自己的測試，關於 Unity Test Runner 的任何資訊，請參考以下網站： https://docs.unity3d.com/2017.4/Documentation/Manual/testing-editortestsrunner.html

寫了測試後，應該會像下圖這樣，可在 Windows > General > Test Runner 查看視窗。

測試寫完後，如何整合到 Github 上？

接下來要透過 Github CI/CD 做自動化測試流程，幫助其他開發者判斷新更動能不能被上傳上去。我們必須在專案目錄下創建 ./github/workflows/main.yml，然後編寫測試流程，如下所示：

main.yml 是一個文字檔，幫助 GitHub 理解怎麼執行自動化流程。

name: Test project

on:
  pull_request:
    branches: [master] # 只有當提交合併請求到 Master 分支時才會觸發流程

jobs:
  test:
    name: Test Unity.
    runs-on: windows-latest
    strategy:
      fail-fast: false
      matrix:
        projectPath: # Unity 專案的根目錄，若設為 . 代表 git 的根目錄就是 Unity 專案目錄
          - .
        testMode:
          - playmode
          - editmode

    steps:
      # Checkout
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive # 如果專案沒用到 Submodule，可以刪除這行
          lfs: true # 如果專案有使用 Git LFS，則設為 True

      # Tests
      - name: Tests
        uses: game-ci/unity-test-runner@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          projectPath: ${{ matrix.projectPath }}
          githubToken: ${{ secrets.GITHUB_TOKEN }}
          testMode: ${{ matrix.testMode }}

      # Editmode Artifact
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: unity-build-${{ github.run_number }}-editmode
          path: artifacts/editmode

      # Playmode Artifact
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: unity-build-${{ github.run_number }}-playmode
          path: artifacts/playmode

解釋如下：

設定只在開發者提交合併請求到 Master 分支時，才進行自動化測試流程
在 windows 環境下執行測試
流程會進行以下步驟：
- checkout 到需要測試的分支
  - git clone 時只會下載最後的 commit（就是要測試的 commit），節省空間和時間
  - 如果專案有用到 git LFS，則把 lfs 設為 true
  - 如果多加一行 submodules: recursive 欄位，讓專案在 clone 時也順便 clone submodule，以遞迴方式 clone，確保所有 submodule 都有下載
- 進行測試
  - 使用 gameCI 的 Unity Test Runner 進行測試，這個 Runner 使用 Docker Image 整合測試環境，這樣每次測試都有獨立環境，是最常見的 Unity CI/CD 整合方式
  - 可參考以下文章
    - https://medium.com/@RunningMattress/setting-up-a-ci-cd-pipeline-for-unity-part-1-344e74c4f35a
  - 會針對 Unity 的 Edit Mode 與 Play Mode 進行測試，分為兩個 Job 並行處理
  - 請確保在測試之前，在 Github 的 config 上驗證 Unity 的身分驗證，這樣 Runner 才能跑測試
    - https://game.ci/docs/github/activation
- 輸出日誌
  - 針對 Edit Mode 與 Play Mode 的測試資料輸出日誌

上傳 yml 到 Github 上，然後嘗試創建一個合併請求（pull request）

Q: 什麼是合併請求？
當開發者用 Git 進行專案版本控制，大家會在自己的分支上進行開發，如果功能完成，可把開發的分支合併到主分支上，以完成專案的某項功能，讓其他開發者使用。但新的開發內容可能影響其他開發者，所以合併前要創建合併請求，讓其他人知道這個功能改哪些程式碼。這時 CI/CD 自動化流程的執行結果就能幫助開發者，審核功能是否可以上傳。

創建後，應該會像圖二這樣進行 CI/CD 流程，並顯示結果。有的話代表已經成功搭建流程！

注意事項

Github 提供的 CI/CD Runner 似乎有記憶體限制，如果專案太大可能沒辦法 CI/CD，這是需要注意的地方。
如果無法執行成功，請查看輸出是否有編譯錯誤。

搭建時遇到的坑

如果程式碼有中文，請轉成 UTF-8，不然傳到 github 上會變成亂碼，輕則影響輸出可讀性，重則影響編譯。