前言：測試都通過了，為什麼還要懷疑？

「AI 幾秒鐘就能幫你的函式產生一整套測試，語法正確、結構完整、跑起來全部綠燈——這樣還不夠好嗎？」

這句話聽起來很合理，卻悄悄替換了一個關鍵問題。它問的是「測試能不能通過」，但真正該問的是「這個測試有沒有測到該測的行為」——這兩件事完全不是同一回事，而且產出速度越快，中間這道落差就越容易被忽略。

今日目標

• 分清楚「測試通過」跟「測試測到了正確的事」是兩個獨立的問題
• 理解 AI 產出測試的速度優勢,如何反過來放大了品質風險
• 認識「語法正確的測試」跟「有效驗證行為的測試」之間的具體落差長什麼樣
• 建立一個檢查測試是否真的測到重點的簡單方法

速度沒有降低的門檻，是「判斷」，不是「產出」

寫一個測試，實際上包含兩件工作：產出測試程式碼（語法、結構、Mock 設定、斷言語法）跟判斷這個測試該驗證什麼、涵蓋哪些情境、斷言是否精確。AI 大幅加速的是前者——語法幾乎不會出錯，結構也符合慣例，這一塊確實被顯著改善了。

但後者完全沒有被加速。要判斷「這個測試值不值得留」，需要理解這段程式碼在業務邏輯上該有什麼行為、有哪些邊界情境、什麼樣的輸入會讓它露出馬腳——這件事需要的是對需求跟系統的理解，不是語法能力。 AI 產出測試的速度越快，人來不及逐一檢查「這個測試到底測到了什麼」的機率就越高，因為看到一長串綠燈通過的測試報告，直覺上就會覺得「應該沒問題」。

一個具體的落差：語法正確,不等於驗證了正確的事

用一個簡單的例子感受這個落差。假設要測試一個「計算訂單折扣後金額」的函式：

❌ 語法正確，但沒有真正驗證行為：
test('計算折扣金額', () => {
  const result = calculateDiscountedPrice(100, 0.1);
  expect(result).toBeDefined();
});
→ 測試會通過，因為函式確實回傳了一個值，
  但這個測試完全沒有驗證「回傳的值是不是 90」，
  函式回傳任何非 undefined 的東西都能讓這個測試綠燈

✅ 真正驗證了預期行為：
test('輸入 100 元與 10% 折扣，應回傳 90 元', () => {
  const result = calculateDiscountedPrice(100, 0.1);
  expect(result).toBe(90);
});
→ 測試名稱說明了具體情境跟預期結果，
  斷言精確到具體數值，函式邏輯真的錯了才會失敗

第一個測試在報告裡看起來跟第二個一樣「通過」，但它對重構完全沒有防護力——就算把折扣計算邏輯改壞成永遠回傳 0，這個測試依然是綠燈。「測試通過」這個訊號本身沒有告訴你任何關於「這個函式對不對」的資訊,除非斷言本身就是精確的。

為什麼 AI 特別容易產出第一種測試

AI 在缺乏足夠業務脈絡的情況下，傾向寫出「保證會通過」的測試，而不是「真正有機會失敗、藉此驗證行為」的測試——這不是 AI 故意偷懶，而是在資訊不足時，「先讓測試通過」是一個統計上安全的選擇。如果只給 AI 看函式簽章跟一句簡短描述，沒有明確講清楚預期的輸入輸出對照，AI 很難自己推導出精確的斷言值，於是就傾向寫寬鬆、不容易失敗的判斷式（例如 toBeDefined()、toBeTruthy()），而不是具體數值比對。

AI 寫測試的品質，直接反映了它拿到的業務脈絡有多完整——這也是為什麼「AI 讓寫測試變快」這件事，不能單獨評估「AI 寫測試的能力」，還要評估「人有沒有把該給的脈絡給到位」。脈絡沒給夠，AI 產出的速度優勢，換來的是一堆看起來完整、實際上沒有防護力的測試。

今日思考題

回想你上一次讓 AI 幫你寫測試的經驗：那些測試的斷言，是精確比對具體的值，還是只確認「有回傳東西」「沒有拋出例外」這種寬鬆判斷？如果現在故意把待測函式的邏輯改壞，這些測試裡有幾個真的會變紅？

今日重點回顧

• 寫測試包含「產出」跟「判斷」兩件事,AI 大幅加速的是產出,判斷這件事的門檻完全沒有降低
• 「測試通過」不等於「測試測到了正確的事」，寬鬆斷言可以讓任何實作都通過
• AI 產出測試的品質，直接反映了它拿到的業務脈絡夠不夠完整——脈絡不足時，AI 傾向寫保證會通過的寬鬆斷言
• 檢驗測試是否有效的簡單方法：故意把邏輯改壞，看這個測試會不會變紅

明日預告

明天用一個具體案例，示範「AI 生成的測試全綠，卻沒測到任何有意義的行為」這件事實際發生時長什麼樣子——以及事後回頭看,那個測試報告的綠燈到底騙了誰。