Assertion 中文叫斷言,白話就是「驗證」:測試裡負責檢查結果對不對的那幾行。一個測試如果沒有斷言,它會把動作做完、然後回報通過,永遠通過。這種測試比沒有測試更糟,因為它給你假的安全感。這篇教你看斷言、判斷斷言夠不夠、要求 AI 補強。

先看一個危險的例子

圖 1:沒有斷言的測試,功能全壞也照樣綠燈

左邊的測試打開登入頁、填了帳密、按了按鈕,然後就結束了。它沒有檢查任何結果。

這代表什麼?就算按下按鈕後系統噴出錯誤頁,這個測試依然綠燈,因為「點擊」這個動作本身有做成功。像一個保全,巡邏路線都走完了,但一路上沒檢查任何一扇門有沒有鎖。

右邊補上兩個斷言後就不一樣了:沒導向 dashboard、或使用者名稱沒出現,立刻變紅。

AI 產出的測試偶爾會長成左邊那樣,特別是你的指令只講了操作、沒講預期結果的時候。回想第 5 篇:預期結果是斷言的原料,你沒給,它只能產出動作。

五種常用斷言,照英文唸就懂

圖 2:五種最常用的斷言

一個一個講,每個配一個使用時機:
• toBeVisible():這個東西應該看得到。用在確認訊息、按鈕、區塊有沒有出現。最常用的一個。
• toHaveText(...):這個東西的文字應該是某某。用在驗證錯誤訊息的內容對不對,不只是有沒有出現。
• toHaveURL(...):現在的網址應該是某某。用在確認有沒有導向正確的頁面,例如登入後該到 /dashboard。
• toHaveCount(n):這種東西應該有 n 個。用在清單筆數、搜尋結果數。
• toBeEnabled() / toBeDisabled():按鈕應該可以按,或不能按。用在表單沒填完時,送出鈕應該是鎖住的。

讀 AI 產出的測試時,有個實用的小技巧:把每行 expect 翻成中文唸一遍,那就是這個測試的驗證清單。然後拿這份清單對照你心裡的測試案例,缺的,就是要請 AI 補的。

有斷言還不夠,再問三個問題

斷言存在,不代表斷言夠好。審查時照順序問:

第一問:它驗的是「結果」還是「動作」?「按鈕被點擊了」是動作,「訂單出現在列表上」才是結果。動作成功,不代表功能正確。

第二問:驗證的位置夠深嗎?測「新增成功」,斷言只檢查了成功訊息彈出來,還是有進一步確認資料真的出現在清單裡?訊息可能是前端寫死的,資料才是真相。這種「訊息說成功、資料其實沒存」的 bug,你大概親手抓過。

第三問:反向情境有驗嗎?輸入錯誤密碼時,除了「登不進去」,有沒有驗錯誤訊息的內容?錯誤處理是最常被略過、也最常藏 bug 的地方。

拿第二問實際走一次,看「驗淺」和「驗深」差在哪。場景就用官方示範站的待辦清單(demo.playwright.dev/todomvc),新增一筆「買牛奶」。驗淺的版本:

await page.fill('#new-todo', '買牛奶');
await page.click('#add-btn');
await expect(page.getByText('新增成功')).toBeVisible();

這個測試會過,但它只證明了「訊息有跳出來」。如果後端存檔失敗、前端還是照跳成功訊息(這種 bug 真實存在),它照樣綠燈。驗深的版本多兩行:

await expect(page.getByText('新增成功')).toBeVisible();
await expect(page.locator('.todo-item')).toHaveCount(1);
await expect(page.getByText('買牛奶')).toBeVisible();

補的兩行在驗「資料真的進了清單」:筆數變 1,而且內容就是剛輸入的那筆。訊息是宣稱,資料是事實,兩個都驗才踏實。

這三個問題可以直接變成給 AI 的指令:

你可以這樣對 Claude Code 說:

檢查這個測試的所有斷言:
1) 有沒有只驗動作、沒驗結果的地方?
2) 「成功」的判定夠不夠深入,還是只看了表面訊息?
3) 幫我加一個反向情境:輸入錯誤密碼時,應顯示「帳號或密碼錯誤」且停留在登入頁。

斷言太多,也是問題

反過來,AI 有時會太熱心,一個測試塞十幾個斷言,連按鈕顏色、字型都驗。

這有兩個壞處。一是測試的意圖被稀釋:失敗時看不出這個測試到底在守護什麼。二是無關緊要的小改動(文案微調)就讓它變紅,久了大家對紅燈麻痺。紅燈太常亂叫,就沒人理它了,這是測試信任的頭號殺手,後面幾篇我會反覆提醒大家這個主題。

原則:一個測試守護一件事,裡面的斷言都應該服務那件事。

今天的練習
• 在 TodoMVC 實做一次驗深:新增「買牛奶」後,除了筆數,再驗內容(清單裡的文字就是「買牛奶」)和剩餘數(1 item left)。三個斷言各自守什麼,講給自己聽。
• 打開你手上任何一個測試,把 expect 都翻成中文,列出驗證清單,對照心裡的測試案例找缺口,請 AI 補上。
• 反向操作一次:挑一個斷言問 AI「如果功能壞了,這個斷言還是綠的,可能是什麼情況?」看它答出什麼盲點。