那你憑什麼期待 AI 幫你做好測試？
當越來越多開發人員開始用 AI 寫程式時，有一件事情其實很少被點破：
AI 之所以能幫你寫出像樣的程式，是因為你餵給它夠多「好的開發原則」。
你會在 Prompt 裡告訴它：
- 要有清楚的命名
- 要符合 SOLID
- 要考慮可讀性與可維護性
- 要寫乾淨的錯誤處理
- 要避免 side effect
- 要有合理的 abstraction
甚至你會在 MD、在 coding guideline、在既有程式碼裡，不斷示範什麼叫「好程式碼長什麼樣子」。
結果是什麼？AI 是被你教會什麼是品質，它並不是一開始就「自己學會寫好程式」。
那為什麼一談到測試，就只剩下「全都要測」？
有趣的是，輪到測試的時候，很多人的期待突然變得極度粗糙：
-「你幫我把這個功能都測到」
-「幫我寫單元測試」
-「不要漏掉任何情境」
這些話聽起來很認真，但本質上其實跟下面這句一樣空洞：「幫我寫一份很好的程式。」
或許你會認為AI 不會測試，但是實際上是你根本沒有告訴它，什麼叫「好測試」。
AI 做不好測試，往往只是忠實反映你的測試素養
如果你給 AI 的測試指示只有：
- 覆蓋率要高
- 每個 function 都要有 test
- 成功失敗各測一次
那它產出的自然會是：
- 一堆只在驗證 happy path 的測試
- 幾乎沒有邊界條件
- 對錯誤情境毫無洞察
- 測試存在，但對風險沒有幫助
這是因為它完全照你描述的品質標準在做事。就像你只跟 AI 說「效能要好」，卻沒告訴它 latency、throughput、資源限制一樣。
好測試不是「測很多」，而是「知道為什麼要測」
真正能讓 AI 把測試做好的，是測試背後的思考 discipline，沒有有品質的 Prompt，出來的大多是垃圾。
例如，你如果能清楚告訴它：
- 哪些是業務規則的邊界
- 哪些輸入是等價類
- 哪些條件組合才是真正有風險的 decision point
- 哪些錯誤是系統最不能承受的
- 哪些情境測了也沒價值，反而增加維護成本
- 需要具體的輸入資料，而不是兩個整數之類的模糊敘述
AI 其實可以把這些思路，轉譯成相當具體、結構化的測試案例。
但前提是：你自己要先知道這些測試 practice 是什麼。
你不是在「用 AI 測試」，你是在「教 AI 什麼是測試」
這也是很多開發人員現在卡住的地方。他們以為學會怎麼下 Prompt 就夠了，
卻忽略了一個現實：
Prompt 的品質，來自你對該專業領域的理解深度。
你不懂測試設計技巧，你就只能叫 AI「幫我多寫一點測試」。你理解測試的目的、風險與取捨，你才能跟 AI 討論：
- 這裡值不值得測？
- 哪些情境應該合併？
- 哪些測試放在單元層就好？
- 哪些風險應該往整合或驗收層推？
這時候，AI 才會真的像一個高效率的測試助理，否則就會是測試樣板產生器。
在 GenAI 時代，測試不會變得不重要，只會變得更赤裸
AI 讓一件事情變得非常明顯：
- 你不懂的，它補不起來
- 你模糊的，它只會放大模糊
- 你沒有原則的，它就只能照表操課
所以真正的問題從來不是：「AI 能不能幫我把測試做好？」
關鍵會是：「我到底有沒有能力，定義什麼叫好測試？」
如果答案是否定的，那你現在看到的 AI 測試品質，其實已經很誠實了。
結語：
學測試，是為了能請 AI 把測試寫對，不是因為用了AI，它就可以幫你處理好測試。
在過去，測試能力不足，還可以靠人力補。
在 AI 開始接手大量產出的時代，測試能力不足，會直接反映在你交付的品質上。
如果你希望 AI 真正幫得上忙，那測試的 principle、discipline、practice，就不再只是測試人員的事了。那是你能不能駕馭 AI 的基本功之一。
發表迴響