單元測試產生器

🍽 這道菜在做什麼

寫單元測試是每個工程師都知道該做、卻最常被砍掉的工作。趕上線時測試先放一邊，等到改了一行程式把別的地方弄壞、線上出包才後悔。難的不是寫測試本身，而是「想齊所有該測的情況」——正常輸入大家都會測，真正會出事的是邊界與例外：傳進來的是 null、空陣列、零、負數、超大數字、格式不對的字串。這些案例最累人，要逐一想清楚，偏偏漏掉的往往就是它們。

這道配方讓你把一個函式或模組貼進去，AI 就幫你把測試案例分成「正常、邊界、例外」三類列清單，再產出一整份可執行的測試碼，最後還反過來指出你原始程式裡「行為不明確、測不出來」的地方。最需要它的是三種人：時間被壓得很緊、想快速補上測試覆蓋率的工程師；負責找漏洞、要系統性窮舉邊界的 QA；以及正在學測試怎麼寫、想看一份結構完整範例的自學者。一個原本要花半小時手刻的測試檔，這樣幾分鐘就有雛形，而且因為 AI 特別擅長補你想不到的邊界，常常會幫你提前抓到還沒爆的 bug。想找更多開發者用得上的提示詞，可以逛 /recipes。

為什麼這樣設計

這段提示詞的第一個關鍵，是強迫 AI「先列清單、再寫程式」，而且清單要分成正常、邊界、例外三類。如果直接叫它「寫測試」，它通常只會生幾個 happy path（正常情況）就交差。先列清單這一步把思考攤開來，你能一眼檢查「啊，它沒測空字串」、「金額為負的情況漏了」，補一句就能讓它加上，比起埋在程式碼裡逐行找漏洞快得多。

第二個關鍵是明確指定「語言與測試框架」。Python 的 pytest、JavaScript 的 Jest、Java 的 JUnit，斷言寫法、mock 方式、檔案結構都不一樣。先講清楚，它才會給你能直接貼回專案跑的程式，而不是一份還要大改的偽碼。第三個、也是最有價值的設計，是請它「指出原始程式中行為不明確的地方」。這把 AI 從「測試工人」升級成「審稿人」——它在試圖窮舉案例時，會發現你的函式遇到字串型別的金額沒處理、除以零沒擋、回傳值在某種輸入下不確定。這些是你自己看程式碼很難察覺的盲點。最後請它「預估覆蓋重點」，讓你知道這組測試守住了哪些行為、還有哪裡沒顧到，方便決定要不要再補。

怎麼用

第一步，到指定的 AI 對話工具，複製整段提示詞。第二步，在「程式語言與測試框架」填上你的組合，例如「Python + pytest」或「JavaScript + Jest」——這步別省，框架不同產出差很多。第三步，把要測的函式或模組完整貼進 {貼上函式}，連同它依賴的型別或常數一起貼，AI 才看得懂上下文。第四步按 Enter，先看它列的測試案例清單，確認正常、邊界、例外三類都涵蓋到你在意的情況，缺的當場補一句請它加。第五步，把產出的測試碼貼回專案實際執行——這是不能跳過的一步。AI 產的測試偶爾會有小錯（import 路徑、斷言寫反、mock 沒設好），一定要實跑確認全綠才算數。這正好對應配方的三個步驟：貼函式、看測試清單、跑測試驗證。

調整技巧

結果不夠到位時，用講的調整即可。覆蓋不夠就說「請針對邊界值再加測：空輸入、最大最小值、剛好等於門檻的數字」。想走 TDD（測試先行）流程，別貼實作，改貼規格——「這個函式應該滿千折百、上限折五百」，請它先寫測試再寫程式，正好是配方的「TDD 版」。要壓力測試健壯性，用「邊界轟炸版」請它專門針對極端與惡意輸入加測，例如超長字串、特殊字元、SQL injection 樣式的輸入。如果測試太瑣碎重複，回它「請用參數化測試（parametrize）把同類案例合併」。想要它順手補上 mock 外部依賴（資料庫、API），直接說「這裡會打外部 API，請用 mock 隔離」。把這些測試接進自動化流程的做法，可以到 /workflows 找 CI 相關的配方。

注意事項

AI 產的測試是助力，不是保證。最重要的一條：測試一定要在你自己的專案裡實際跑過、看到全部通過，才能信。沒跑過的測試等於沒有測試，AI 可能用了錯的 import、假設了不存在的函式、斷言寫反方向。第二，AI 是「根據程式碼推測該有的行為」來寫測試，但程式碼本身可能就是錯的——如果你的函式有 bug，AI 可能會把錯誤行為當成正確的去測，反而把 bug「鎖死」。所以它指出「行為不明確」的地方時，要回去看規格確認正確行為是什麼，而不是盲目接受。第三，涉及金流、計費、權限判斷這類關鍵邏輯，測試通過只代表「符合你寫的斷言」，最終仍需人工複查斷言本身對不對，AI 不能取代你對業務規則的判斷。第四，貼程式碼時避免把含真實金鑰、密碼、客戶個資的片段貼進對話框，先換成假值。

台灣情境案例

台北一家做電商後台的新創，工程師小婷接手一段沒人寫過測試的「運費計算」函式：滿 1000 免運、外島加收、超商取貨另計。她趕著上促銷檔期，沒空慢慢補測試。她把函式貼進這道配方，框架填 Python + pytest。AI 先列出清單：正常（一般金額算正確運費）、邊界（剛好 1000、999、1001）、例外（金額為負、None、外島代碼填錯）。更關鍵的是，它在第三區塊指出：「你的函式沒處理金額為字串的情況，且外島判斷只比對縣市名稱，遇到『澎湖縣』和『澎湖』會行為不一致，建議先釐清。」小婷一看才驚覺，這正是上週客訴「澎湖客人沒被加收外島費」的真正原因。她把測試碼貼回專案實跑，修掉那個比對 bug，再讓全部測試轉綠才上線。原本她預估補測試要花一個下午，實際四十分鐘搞定，還順手抓到一個正在線上漏錢的 bug。

延伸用法

這道配方不只用在補既有程式的測試。開新功能時，用「TDD 版」先寫測試再寫實作，能逼自己先把規格想清楚，寫出來的程式天生好測。重構舊程式碼前，先用它補一層測試當安全網，改完跑一次就知道有沒有改壞行為。處理外部回傳的資料解析（JSON、CSV、第三方 API 回應）時，用「邊界轟炸版」灌各種畸形輸入，是最划算的防呆投資。它也能幫你把測試標準化：請它依你團隊的命名慣例與註解風格產出，貼進專案就維持一致。想把「產生測試」做成一個可重複呼叫的小工具或範本，可以到 /generator 看產生器類的配方，把這套流程沉澱成團隊資產。

材料

• AI 對話工具（Claude／ChatGPT／Gemini）
• 要測試的函式或模組

步驟

1. 貼函式：附上語言與你用的測試框架。
2. 看測試清單：先確認案例涵蓋正常、邊界、例外。
3. 跑測試驗證：把測試碼貼回專案實際執行，確認都通過。

配方本體（可複製帶走）

# 任務
請為以下函式／模組產生完整的單元測試。

程式語言與測試框架：{例如 Python + pytest／JavaScript + Jest}
程式碼：
{貼上函式}

請輸出：
1. 測試案例清單（先列要測什麼，分成：正常輸入、邊界值、例外／錯誤輸入）
2. 完整可執行的測試程式碼，每個測試加上清楚的命名與註解
3. 指出原始程式碼中「測不出來」或「行為不明確」的地方，建議我先釐清
4. 預估這組測試的覆蓋重點
繁體中文說明，程式碼用原語言。

試吃報告

變化版

• TDD 版：先給規格不給實作，請它先寫測試再寫程式。
• 邊界轟炸版：請它專門針對極端輸入與惡意輸入加測。

你可能也想看