這篇文章會分享設計上要注意的細節，以及實戰過程踩過的坑，不會特別說明基礎資訊，想更深入理解的朋友可以參考官網文件；如果讀者有更好的方案，或對名詞有更精準的定義，歡迎留言分享。

文章大綱

▋ GitLab CI 資料夾結構設計
▋ 在 .gitlab/.default.gitlab-ci.yml 定義要執行 pipeline 的 Branchs
▋ 根據專案需求定義對應的 Stages
▋ 想在不同 stage 傳遞資料時，artifacts 跟 cache 的使用時機
▋ 讓 stage 下的 job 並行執行 or 順序執行
▋ notify 階段建議要有的資訊
▋ Dockerfile 多階段構建
▋ 其他的坑（套件安裝、相容性、單元測試）

GitLab CI 資料夾結構設計

Project
├── .gitlab-ci.yml
└── .gitlab
    ├── stages
    │   ├── 1.xxx.yml
    │   └── 2.xxx.yml
    ├── .default.gitlab-ci.yml
    └── docker-bake.hcl

下面說明一下資料夾結構下各檔案要負責的任務：

• .gitlab-ci.yml: 定義有要執行的 stages，以及參考的 yml 檔案（ex: .gitlab/.default.gitlab-ci.yml）。
• .gitlab: 存放 GitLab 設定檔的資料夾。
• .gitlab/stages: 存放各 stage 的資料夾，讓邏輯更容易維護。
• .gitlab/stages/xxx.yml: 定義 stage 下各 jobs 要執行的任務。
• .gitlab/.default.gitlab-ci.yml: 用來定義默認的設定，避免重複性的工作（ex: 設定通用的 variables、定義要執行 pipeline 的 branchs）。
• .gitlab/docker-bake.hcl: 定義 Build Docker Image 的資訊（ex: 支援多平台、傳遞參數）。

在 .gitlab/.default.gitlab-ci.yml 定義要執行 pipeline 的 Branchs

僅管我們期待每次 Push 一版都會觸發 pipeline，但有時也會有一些例外狀況（ex: 需要高頻率 Push 測試一些特殊功能）。

以下面的設計來說，就是僅允許「merge_request_event」以及「release/、hotfix/、feature/*」，還有 Default Branch（ex: master、develop）會觸發 pipeline。

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH =~ /^release\/.*$/'
    - if: '$CI_COMMIT_BRANCH =~ /^hotfix\/.*$/'
    - if: '$CI_COMMIT_BRANCH =~ /^feature\/.*$/'
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'

根據專案需求定義對應的 Stages

筆者習慣設計下面 5 個 Stages:

• init: 在這個階段做套件安裝的任務（ex: npm install）。
• analysis: 如果 init 順利才會進入這個階段，會在這裡進行單元測試(test)、Coding Style 檢查(lint)，並將對應的 report 保存到 artifacts 當中。
• build_image: 如果前面都通過才會 Build Docker Image，並將 $TARGET_IMAGE:$TAG 保存到 artifacts/tags.txt 當中（要在 notify 階段使用）。
• notify: 我將它設定為 always 執行，用來傳送 pipeline 成功/失敗的訊息到對應的 Chanel（ex: Zoom、Teams、Line）。
• deploy: 根據實際需求設計部署流程。

想在不同 stage 傳遞資料時，artifacts 跟 cache 的使用時機

上個 stage 做完的事情，在下個 stage 是不會知道細節的。

想要傳遞資訊就需要透過 artifacts 或 cache，而這兩者的用途不太一樣：

• artifacts: 記錄這次 pipeline 獨有的資訊，像是 test report、image_id 這類的，建議要設定對應的 expire_in 時間，否則資料會永久保存消耗硬碟空間。

analysis:
  artifacts:
    paths:
      - reports
    expire_in: 1 day

• cache: 這個專案經常使用的資料，比如 node_modules 這類保存套件的資料夾。

analysis:
  cache:
    key: "${CI_PROJECT_PATH_SLUG}"
    paths:
      - node_modules

讓 stage 下的 job 並行執行 or 順序執行

如果沒有特別設計，stage 下的 job 默認都是並行執行的（比如 unit test & lint 可以同時進行）；如果想要順序執行，可以透過 needs 來設定，範例如下：

job1:
  stage: build
  script:
    - echo "Executing job1"
job2:
  stage: build
  script:
    - echo "Executing job2"
  needs:
    - job1  # 等待 job1 完成後執行

notify 階段建議要有的資訊

GitLab CI 通常要跑幾分鐘的時間（通常跟 unit test 多寡有關），所以要設計 notify 的機制來傳遞資訊，建議包含的內容如下：

• project: $PROJECT_NAME，方便了解執行的專案。
• branch: $CI_COMMIT_REF_NAME，了解哪個 branch 更新了。
• result: 會包含成功與失敗的詳細資訊。
• pipeline_link: $PIPELINE_LINK，出問題時點擊連結可以看到最直接的資訊。
• image_id: 從 artifacts 裡面讀取。

Dockerfile 多階段構建

下面用一個範例來說明如何用多階段構建（multi-stage build）來減少 Docker Image 大小並提高效率（COPY –from=builder 的作用是從第一階段複製文件到第二階段）。

# 第一階段：使用 Node.js 安裝套件，並進行打包
FROM node:23.3-alpine as builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
RUN npm run build

# 第二階段：使用 Nginx 部署靜態文件
FROM nginx:alpine3.20
COPY --from=builder /app/dist /usr/share/nginx/html
WORKDIR /usr/share/nginx/html
COPY ./build/nginx/default.conf /etc/nginx/conf.d/default.conf

透過這個方案，最終的 Image 只有靜態文件跟 Nginx，不包含 Node.js 開發工具；不但減少 Image 大小，還減少了潛在攻擊面向。

其他的坑（套件安裝、相容性、單元測試）

• 套件無法順利安裝: 如果套件是經由私有庫來安裝的，就需要設定對應的網路環境；如果在 Dockerfile 裡面安裝，請記得將 .npmrc 這類設定 COPY 到對應的位置。
• qemu-user-static 相容性錯誤: 有些專案需要指定對應的 platform 才能順利 build 出來（Dockerfile from 的 image 可能僅支持 arm 或 amd）。
• 單元測試錯誤突然暴增: 如果在 local 環境測試起來正常，但在 GitLab CI 時出現錯誤，那通常是「非同步」的問題，可以先用 await 拉長等待時間，並搭配 log 來釐清狀況。

有段時間沒發純技術的文章了，希望能幫助到有相關需求的朋友們，也歡迎大家分享自己在 GitLab CI 的使用經驗。

如果問我 ChatGPT 對普通人來說最大的幫助是什麼，我覺得應該是獲得「主管、老闆」交代事情的權利吧！

如果所有任務都要「事必躬親」，那再多的時間也不夠用；反過來，如果能把一些瑣事交代出去，我們的時間就變多了。

今天筆者就來分享幾個能直接使用的案例，希望能幫讀者爭取更多屬於自己的時間。

大綱

▋ 公文撰寫（ex：系統升級需要暫停服務）
▋ 履歷撰寫
▋ 公司活動企劃（ex：自強活動）
▋ 文案發想
▋ 讓你的文字更為通順
▋ 結論：每個人都用得到的技術

因本篇文章涉及大量對話，考慮到閱讀體驗性，故用文字取代截圖。

公文撰寫（ex：系統升級需要暫停服務）

有時工作上會遇到公文撰寫的需求，如果是第一次接觸，那光是找範例、用字遣詞就會浪費不少時間。

這類繁瑣的工作我覺得交給 ChatGPT 完成就好，而且可以根據你的需求改變語言。

我：「想請你幫我寫一則公告，目前公司的系統基於安全性考量需要升級，需要在 1 月 20 號下午 2 點到 3 點進行維護。」

ChatGPT：「

尊敬的客戶，

為了確保系統的安全性，我們將於1月20日下午2點至3點進行系統升級維護工作。在這段時間內，系統將無法使用。我們將盡快完成維護工作，並盡快恢復服務。

對給您帶來的不便表示歉意，謝謝您的理解與配合。

如有任何疑問，請隨時與我們聯繫。

謝謝。

公司名稱」

我：「幫我做一個英文版。」

ChatGPT：「
Dear valued customers,

We will be conducting scheduled maintenance on January 20th from 2pm to 3pm to ensure the security and integrity of our systems. During this time, our services will be temporarily unavailable. We apologize for any inconvenience this may cause and assure you that we will work diligently to complete the maintenance as quickly as possible.

If you have any questions or concerns, please do not hesitate to reach out to us.

Thank you,

Company Name」

他可以撰寫公文，同樣也能幫你完成日常的電子郵件喔（請對方幫忙某件事、感謝信、辭職信…）！

履歷撰寫

筆者過去擔任面試官時，最常遇到的就是候選人給的「資料不完善」，造成許多經歷我無法有效評估，而 ChatGPT 產生的履歷儘管中規中矩，但至少該提的部分都有放上去。

在履歷撰寫的部分，你提供 ChatGPT 越多關鍵字，他就能組合出越符合你需求的履歷。

我還真沒想到丟 GCP K8s 這個關鍵字，他就幫我把 Docker 微服務這些東西整合出來，是真的有在思考的。

我：「幫我用繁體中文寫一份讓面試官眼睛一亮的求職履歷。我是一名 Backend 工程師，有 5 年的工作經驗，熟悉 Node.js、MYSQL、PostgreSQL 等技術，也有 GCP K8s 的經驗，做過 RMA、OTA 等系統。」

ChatGPT：「
[個人資料]
姓名：XXX 電話：XXX email：XXX

[教育經歷]

• XXX大學，資訊工程系，學士學位，XX年XX月 ~ XX年XX月

[工作經歷]

• 公司名稱：XXX公司 職稱：Backend工程師 時間：XX年XX月 ~ 至今
• 負責公司核心產品的後端開發，包括RMA、OTA等系統
• 技術框架：Node.js、MYSQL、PostgreSQL
• 使用GCP K8s部署和管理後端服務
• 實施持續交付和持續整合流程，提高開發效率和產品品質
• 負責系統的性能優化，並導入監控和日誌系統，提高系統的可靠性和可追溯性
• 協助團隊成員解決技術問題，提供技術指導
• 參與需求分析、設計、開發、測試、部署等整個軟體開發流程

[技能]

• 熟悉Node.js、MYSQL、PostgreSQL等技術
• 熟悉GCP K8s部署和管理後端服務
• 熟悉微服務架構和持續交付流程
• 熟悉Docker、Kubernetes等容器技術
• 了解常見的性能優化方法和監控工具

[自我評價]

• 具有良好的溝通能力和團隊協作精神
• 積極主動，能夠快速學習新技術
• 熟悉常見的軟體開發流程和工具
• 具有較強的邏輯思考能力和系統思考能力
• 對於軟體開發充滿熱情，不斷追求技術提升和創新

[附加資訊]

• 參與過多個開源專案
• 曾獲得過某IT公司頒發的最佳技術獎」

對筆者來說，透過 ChatGPT 把中文履歷轉換成「英文履歷」是一個很實用的功能，這邊筆者就不再操作，不然有灌水嫌疑 XD（自己寫不好，又不想花錢請人幫忙改的可以嘗試看看 ChatGPT）

公司活動企劃（ex：自強活動）

被交代非職位相關的任務時，你是否煩躁又一頭霧水？

此時你可以把這份工作「外包」給 ChatGPT，讓他幫你收集資料，並提供對應的關鍵字。

我：「公司請我規劃 2 個月後的自強活動，目前公司的人數約 100 人，平均年齡在 40 歲上下，科技業，希望能增加員工間的向心力，請問怎麼規劃比較合適呢？」

ChatGPT：「自強活動是一種用於增強公司團隊精神和員工間向心力的活動。在規劃時，可以考慮以下建議:

1. 團隊建設活動: 安排一些團隊建設活動，如團隊挑戰、團隊冒險、團隊訓練等，讓員工在共同的目標和挑戰下建立團結精神。
2. 社交活動: 安排一些社交活動，如餐會、聚餐、戶外活動等，讓員工能夠增進彼此之間的關係。
3. 專業培訓: 提供專業培訓，如領導力、溝通技巧、團隊建設等，讓員工能夠提升自己的專業知識和技能。
4. 混合活動: 結合多種不同類型的活動，如團隊建設活動、社交活動、專業培訓等，讓員工在多元化的活動中增加向心力。

建議您可以聯繫專業策劃公司來設計符合公司文化和員工喜好的自強活動，同時也可以與員工討論自強活動的需求，讓員工能夠在自強活動中增強團隊精神和增加向心力。」

得到這份結果後，你可以發起一份問卷表單，讓大家投票選擇哪一種自強活動（自己不感興趣的可以事先過濾）。

文案發想

目前實驗下來，ChatGPT 沒辦法寫出一份很好的文案，可能是筆者給的關鍵字與敘述不夠好。

不過在「發想（腦力激盪）」的表現挺不錯的，如果你不滿意這次的回覆，可以點擊「Regenerate response」讓他重新回答這個問題。

我：「我想請你擔任一個文案行銷專家。我舉辦了一場研習會，邀請在臺灣獲得近距離魔術冠軍的朋友當講師，參與活動要收取 1000 元的費用，我要如何寫宣傳文案才能吸引大家報名呢？」

ChatGPT 第 1 次回應：「魔術是一種迷人的藝術，而在台灣，我們擁有一位獲得近距離魔術冠軍的頂尖講師。現在，您有機會在這次研習會中，直接學習他的魔術技巧和秘訣。這不僅是一次驚奇的體驗，還是提升自己的機會。只需 1000 元的費用，您就可以成為下一個魔術大師。快來報名吧，數量有限，先到先得！」

ChatGPT 第 2 次回應：「請先簡單地介紹一下活動的內容，如活動日期、時間、地點、主題、嘉賓等。

接著，可以提出一些亮點來吸引參與者，例如:

• 這是一場獲得近距離魔術冠軍教授的研習會，參與者將有機會學習到專業技巧
• 這是一場非常罕見的機會，參與者將有機會近距離接觸並學習自己喜歡的領域
• 活動費用相對於其他研習會來說是非常合理的，參與者可以獲得高價值的學習體驗
• 活動將有專業的講師教授，參與者將有機會深入了解並提升自己的專業知識

最後，可以鼓勵參與者提前報名，並告知他們可能錯過的機會。」

我覺得 ChatGPT 對文案發想很有幫助，因為如果你不滿意這次的回覆，可以讓他再想一次，或是用「優化文案」這類的關鍵詞。

讓你的文字更為通順

我想應該有很多人在寫文書時會遇到一個狀況，就是某一段話你怎麼寫都不太順暢，此時，你可以把這段話丟給 ChatGPT，詢問他的建議。

像是我就把上面這段話丟給 ChatGPT，大家覺得他的建議如何呢？

如果怕自己的文章、句子有錯漏字，也可以讓 ChatGPT 來審核喔！

結論：每個人都用得到的技術

先前收到網友私訊詢問：「ChatGPT 跟普通人有什麼關係，我能透過他增加收入嗎？」

筆者覺得這篇文章應該有回答到問題，有了 ChatGPT：

• 節省撰寫公文、email 的時間 ➝ 你工作就有更多空擋
• 撰寫履歷有了方向 ➝ 好的履歷，尤其是英文履歷能給你更多機會
• 沒碰過的企劃馬上獲得範本 ➝ 知道接下來要向哪個單位溝通
• 苦惱的文案迸出靈感 ➝ 減少加班的頻率

時間就是金錢，多出來的時間要拿來進修、接外包，還是當薪水小偷就看讀者的安排了（接外包時請符合公司規定）。

很多時候我們要的並不是「最正確的答案」，而是一些建議與發想，讓我們在卡住的時候有方向（如果剛好能直接使用當然是最理想的）。

不過一個技術到底好不好用、局限性在哪裡，真的要自己親自嘗試過才知道；上面分享的都算是較為成功的案例，這幾天筆者其實還做了很多嘗試，像是法律諮詢、旅遊規劃、美食推薦…等。

但實際測試下來發現，這類包含「真實資訊」的問題，ChatGPT 的錯誤率非常「高」，像是給出的法條根本不存在、旅遊的景點真假參半、美食餐廳是虛構的。

所以無論一個工具多方便，讀者還是要秉持獨立思考與小心求證的心態喔！

小提醒：請勿將個人的隱私資訊分享到 ChatGPT 上。

未來筆者會出一系列使用 ChatGPT、openAI 的文章，如果你對這個議題感興趣，可以持續關注我的文章！

想將 AI 導入自己的職場與生活嗎？歡迎購買筆者出版的新書，幫助您在 AI 的浪潮中站穩腳步，並在未來的職場競爭中佔據優勢！

今天這篇文章，筆者會用一個簡易的「登入頁面」，來介紹 @vue/test-utils 這款套件的常用功能：

• 用 get 找出元素（element）
• 用 getComponent 找出元件（component）
• 用 setValue 模擬使用者對元件（component）輸入值
• 透過 wrapper.vm 取得 data 資訊
• 取得元素（element）的 attributes 屬性
• 模擬使用者點擊輸入框（focus）輸入文字，然後離開（blur）的動作
• 當操作錯誤時，能捕捉預期的 error message
• 確認使用者操作系統時，元件的 attributes 如預期改變（ex： disabled、type）
• 當元素採用 v-show 策略時，用 isVisible 進行判斷
• 模擬使用者 trigger button 事件
• 使用 Vue Router 時，頁面是否如預期跳轉

大綱

ㄧ、從測試的角度來設計頁面規格
二、撰寫登入頁程式
三、從測試案例了解 @vue/test-utils 常用的功能
  ▶︎ 測試檔案初始設定
  ▶︎ 用 get 找出元素（element），並確認是有顯示在畫面上的（isVisible）
  ▶︎ 透過 getComponent 取出元件，並指定「input」來 setValue
  ▶︎ 在輸入框輸入後，用 wrapper.vm.xxx 確定 data 的有成功寫入
  ▶︎ 取得元素的 attributes，確認設定符合預期
  ▶︎ 模擬使用者點擊輸入框（focus）輸入文字，然後離開（blur）的動作
  ▶︎ 使用者操作系統時，元件的 attributes 如預期改變
  ▶︎ 模擬使用者 trigger button 事件，觀察頁面是否如預期跳轉（Vue Router）

讀者可以直接到筆者的 Github，將專案 Clone 下來跑跑看，會更好理解裏面的邏輯（順手按個 ⭐ 更好 🤩）。

ㄧ、從測試的角度來設計頁面規格

在第一篇文章有談到 TDD（Test-Driven Development），測試驅動開發。

假使我們要設計一個登入頁，可以訂製如下規格：

基礎元件功能

• 確認 email、password、LoginBtn 元素存在
• 確認 Email 輸入框可以填資料
• 確認 Password 輸入框可以填資料
• Email、Password 輸入後，data 對應的 formData 有存入相應的值
• 預設 Password 輸入框的 type 為 password，不直接顯示

測試錯誤的 Email、Password 情境

• 當 Email 沒有填寫時，跳出 Required 的錯誤訊息
• 當 Email 格式錯誤時，跳出相關錯誤訊息
• 當 Password 沒有填寫時，跳出 Required 的錯誤訊息
• 當 Password 字數不滿 8 位時，跳出相關錯誤訊息

會讓元件屬性改變的行為

• 當 Email、Password 未填寫時，登入按鈕為 Disabled
• 當 Email、Password 格式錯誤時，登入按鈕為 Disabled
• 當 Email、Password 格式正確時，登入按鈕可點擊
• 點擊顯示 Password 的 icon 時，type 會轉換成 text

登入功能

• 輸入錯誤的帳號密碼，會彈出警視窗
• 確認 Router 可以順利導向

上面訂的規格，就是我們後續要測試的情境。

二、撰寫登入頁程式

在 views 資料夾下新增「Login.vue」來做登入頁，幾個重點說一下：

• 使用 dataset（ex：data-test=”xxx”）來做標記，因為 id 或 class 通常都是因為其他用途而存在的，要是 coding 中不小心動到 id 或是 class 會造成測試不通過
• 在 v-text-field 有設計「rules」來做校驗
• 「valid」影響輸入按鈕是否能按，「pwshow」是密碼是否顯示，「loginFail」決定登入失敗的錯誤訊息是否顯示

<template>
  <div class="d-flex align-center flex-column">
    <v-card width="400">
      <v-container>
        <v-form v-model="valid" lazy-validation>
          <v-alert
            v-show="loginFail"
            type="error"
            class="mb-4"
            data-test="loginAlert"
          >
            You are entering an incorrect email and/or password.
          </v-alert>
          <v-text-field
            v-model="formData.email"
            :rules="emailRules"
            label="Email"
            required
            data-test="email"
          ></v-text-field>
          <v-text-field
            v-model="formData.password"
            :append-icon="pwShow ? 'mdi-eye' : 'mdi-eye-off'"
            :rules="[rules.required, rules.min]"
            :type="pwShow ? 'text' : 'password'"
            name="input-10-1"
            label="Password"
            hint="At least 8 characters"
            counter
            @click:append="pwShow = !pwShow"
            data-test="password"
          ></v-text-field>
          <v-spacer></v-spacer>
          <v-btn
            x-large
            block
            :disabled="!valid"
            color="success"
            @click="login"
            data-test="loginBtn"
          >
            Login
          </v-btn>
        </v-form>
      </v-container>
    </v-card>
  </div>
</template>
<script setup>
import { ref, reactive } from "vue";
import router from "@/router";
const valid = ref(true);
const pwShow = ref(false);
const loginFail = ref(false);
const formData = reactive({
  email: "",
  password: "",
});
const emailRules = [
  (v) => !!v || "Required",
  (v) => /.+@.+\..+/.test(v) || "E-mail must be valid",
];
const rules = {
  required: (value) => !!value || "Required",
  min: (v) => (v && v.length >= 8) || "Min 8 characters",
};
const login = () => {
  // 這邊只是為了方便理解，實際上應該要呼叫 api
  if (
    formData.email === "baoboa@mail.com" &&
    formData.password === "baobaocute"
  ) {
    router.push("/home");
  } else {
    loginFail.value = true;
  }
};
</script>

完成後在終端機輸入 yarn dev，然後進入網址：http://localhost:3000

我這邊有調整「src/router/index.ts」，將 Login 的 path 設定為「/」，讀者可以參考 Github。

三、從測試案例了解 @vue/test-utils 常用的功能

這邊會取幾個測試案例來做解說，完成的範例請參考筆者的 Github（順手點個 Star 會讓筆者會開心一整天）。

測試檔案初始設定

我們在 views 資料夾下新增「test」資料夾，並新增「Login.spec.ts」的測試檔案：

• 透過 import 引入我們會使用到的方法
• 這邊透過 beforeEach 來初始化我們要測試 Login.vue

import { describe, it, expect, beforeEach, vi } from "vitest";
import { mount, VueWrapper } from "@vue/test-utils";
import Login from "../Login.vue";
import vuetify from "@/plugins/vuetify";
import router from "@/router";

let wrapper: VueWrapper<any>;
beforeEach(async () => {
  wrapper = mount(Login, {
    global: {
      plugins: [vuetify, router],
    },
  });
});

用 get 找出元素（element），並確認是有顯示在畫面上的（isVisible）

find 也可以達到一樣的效果，但沒找到時並不會回傳錯誤訊息。

it("確認 Email、Password、LoginBtn 元素存在", () => {
  expect(wrapper.get('[data-test="email"]').isVisible()).toBe(true);
  expect(wrapper.get('[data-test="password"]').isVisible()).toBe(true);
  expect(wrapper.get('[data-test="loginBtn"]').isVisible()).toBe(true);
});

透過 getComponent 取出元件，並指定「input」來 setValue

因為 Vuetify 的 v-text-field 是 div 層，所以需要再透過 get 往下找到 input 這個元素。

it("確認 Email 輸入框可以填資料", async () => {
  const emailInput = wrapper.getComponent('[data-test="email"]').get("input");
  await emailInput.setValue("test@mail.com");
  expect(emailInput.element.value).toBe("test@mail.com");
});

在輸入框輸入後，用 wrapper.vm.xxx 確定 data 的有成功寫入

it("Email、Password 輸入後，data 對應的 formData 有寫入相應的值", async () => {
  const formData = {
    email: "test@mail.com",
    password: "qazwsx1234",
  };
  const emailInput = wrapper.getComponent('[data-test="email"]').get("input");
  await emailInput.setValue(formData.email);
  const passwordInput = wrapper
    .getComponent('[data-test="password"]')
    .get("input");
  await passwordInput.setValue(formData.password);
  expect(wrapper.vm.formData).toEqual(formData);
});

取得元素的 attributes，確認設定符合預期

it("預設 Password 輸入框的 type 為 password，不直接顯示", async () => {
  const password = wrapper.getComponent('[data-test="password"]');
  expect(password.get("input").attributes().type).toBe("password");
});

模擬使用者點擊輸入框（focus）輸入文字，然後離開（blur）的動作；並確認操作錯誤時，能捕捉預期的 error message

it("當 Email 沒有填寫時，跳出 Required 的錯誤訊息", async () => {
  const email = wrapper.getComponent('[data-test="email"]');
  await email.trigger("focus");
  await email.get("input").setValue("123"); //先隨便塞值
  await email.get("input").setValue("");
  await email.trigger("blur");
  const emailErrorMsg = email.get(".v-messages__message");
  expect(emailErrorMsg.text()).toEqual("Required");
});

使用者操作系統時，元件的 attributes 如預期改變（ex：Email、Password 填寫正確，登入按鈕 Disabled 移除）

it("當 Email、Password 格式正確時，登入按鈕可點擊", async () => {
  const loginBtn = wrapper.get('[data-test="loginBtn"]');
  expect(loginBtn.attributes().disabled).toBeDefined();

  const formData = {
    email: "baoboa@mail.com",
    password: "baobaocute",
  };
  const email = wrapper.getComponent('[data-test="email"]');
  await email.trigger("focus");
  await email.get("input").setValue(formData.email);
  await email.trigger("blur");
  const password = wrapper.getComponent('[data-test="password"]');
  await password.trigger("focus");
  await password.get("input").setValue(formData.password);
  await password.trigger("blur");

  expect(loginBtn.attributes().disabled).toBeUndefined();
});

模擬使用者 trigger button 事件，觀察頁面是否如預期跳轉（Vue Router）

it("確認 Router 可以順利導向", async () => {
  const formData = {
    email: "baoboa@mail.com",
    password: "baobaocute",
  };
  const email = wrapper.getComponent('[data-test="email"]');
  await email.trigger("focus");
  await email.get("input").setValue(formData.email);
  await email.trigger("blur");
  const password = wrapper.getComponent('[data-test="password"]');
  await password.trigger("focus");
  await password.get("input").setValue(formData.password);
  await password.trigger("blur");
  // 使用真實的 Router 測試時，若想要捕捉 Push 的行為，須透過 vi.spyOn 來模擬 router.push
  const spyPush = vi.spyOn(router, "push");
  await wrapper.get('[data-test="loginBtn"]').trigger("click");
  expect(spyPush).toHaveBeenCalledTimes(1);
  expect(spyPush).toHaveBeenCalledWith("/home");
});

在文章的最後，筆者也放一下所有測試的結果圖（可透過套件 or 指令 yarn test 執行）：

今天的文章就分享到這邊，我們下次再見～

🤔 今日目標

• 建立一個簡易的請假流程（填寫請假單→主管簽核→依簽核結果執行不同流程）
• 將 Forms + Teams + Power Automate 工具串連起來

💡 開始實作流程

新增 Form 表單

SETP 1 : 在 Forms下新增表單

SETP 2 : 填上標題與描述

SETP 3: 新增問題

對方填寫問題的資訊都能成為之後訊息組合的一部分

在 Teams 新增一個請假專用頻道

STEP 1 : 新增頻道

STEP 2 : 填寫頻道資訊

在 Power automate 新增流程

STEP 1 : 建立自動化流程

STEP 2 : 選擇自動流程要觸發的程序

STEP 3 : 在表單識別碼的地方選擇剛建立的 Form

STEP 4 : 新步驟，取得 Form 表單回覆的內容

STEP 4 : 選擇你要接收哪個表單的資訊

STEP 5 : 新步驟，設定簽核機制

STEP 6: 填寫主管簽核時會看到的內容

STEP 6 : 新步驟，建立簽核觸發條件

STEP 6 : 用簽核結果來處理接下來流程

STEP 6 : 如果簽核結果為是就將訊息 post 到 teams 群組

STEP 7 : 填寫要發布的團隊及頻道，撰寫訊息

STEP 8 : 如果簽核結果為否，就回 email 說明

STEP 9 : 填寫 email 內容

STEP 10 : 將流程儲存

測試流程是否符合預期動作

SETP 1 : 開始測試流程

SETP 2 : 填寫表單確認流程觸發

SETP 3: 拒絕請假

SETP 4: 接受請假

雖然是一個超簡單範例，但實際動手操作起來也是要花一段時間才能完成需求的，希望今天的教學能給需要的人幫助喔～