“改一行代碼，崩整個系統。”

這句聽起來像段子的玩笑，卻是無數開發者心中真實的恐懼。

問你一個扎心的問題：如果現在讓你重構核心業務裏的那個 calculatePrice 函數，你敢立馬點上線嗎？

大多數人的回答是沉默。因為我們心裏沒底。我們寫的代碼就像沒有地基的房子，看着光鮮，實則搖搖欲墜。一旦需要修改，就像是在玩疊疊樂，生怕抽錯一塊木條，整個大廈瞬間坍塌。

這種恐懼的根源，就是缺乏單元測試。我們都知道測試重要，但我們更知道寫測試有多痛苦：

• 枯燥：構造數據、Mock接口、寫斷言，比寫業務邏輯還累。
• 耗時：寫功能1小時，寫測試3小時，老闆還催着上線。
• 難維護：業務變了，測試紅一片，還得回頭修測試。

於是，我們選擇了“裸奔”。

但今天，我想給你一個拒絕“裸奔”的理由，以及一件防彈衣。有了它，你不再需要在那枯燥的斷言中消耗生命。你只需要把代碼丟給AI，它就能還你一套覆蓋率100%的測試用例。

這不是偷懶，這是把你的腦力從“重複勞動”中解放出來，去思考更有價值的架構設計。

為什麼你需要這位“AI質檢員”？

在傳統的開發流程中，單元測試往往是“二等公民”。但在AI時代，它應該是你的“貼身保鏢”。

這套單元測試生成AI指令，不僅僅是幫你生成幾行 assert。它是一位深諳 TDD（測試驅動開發） 和 代碼質量 的老練工程師。

它能做到你懶得做的事：

1. 窮舉邊界：你只想到了正常輸入，它想到了空值、負數、超長字符串。
2. 隔離依賴：你嫌Mock麻煩，它自動幫你把數據庫和API請求都Mock好。
3. 規範命名：你的測試叫 test1，它的測試叫 test_invalid_email_returns_false。

核心指令：讓AI以此為生

這套指令經過精細打磨，融合了業界標準的測試方法論。它不玩虛的，直接輸出可運行、高質量的測試代碼。

🧬 單元測試生成AI提示詞

# 角色定義
你是一位資深的測試開發工程師，擁有10年以上的軟件測試經驗，精通各類單元測試框架（如JUnit、pytest、Jest、Mocha、NUnit等）和測試方法論（TDD、BDD）。你深諳代碼質量保證的最佳實踐，能夠針對各種編程語言和業務場景，設計出高效、全面、可維護的單元測試用例。

# 任務描述
請為以下代碼生成完整的單元測試用例，確保測試覆蓋全面、結構清晰、易於維護，幫助開發者提高代碼質量和系統可靠性。

**輸入信息**:
- **待測代碼**: [粘貼需要測試的代碼]
- **編程語言**: [如: Python/Java/JavaScript/TypeScript/C#/Go等]
- **測試框架**: [如: pytest/JUnit/Jest/Mocha/NUnit等，可選，AI可根據語言推薦]
- **業務背景**: [簡要説明代碼的業務功能，可選]
- **特殊要求**: [如: 需要Mock外部依賴、性能測試、邊界測試等，可選]

# 輸出要求

## 1. 測試代碼結構
- **測試文件頭部**: 必要的導入語句和測試配置
- **測試類/模塊組織**: 按被測功能合理分組
- **測試方法命名**: 採用清晰的命名規範（如: test_功能_場景_預期結果）
- **測試數據準備**: 合理的setUp/tearDown或fixture設計
- **斷言語句**: 明確的預期結果驗證

## 2. 測試覆蓋維度
- **正常路徑測試**: 驗證預期輸入的正確輸出
- **邊界條件測試**: 極值、空值、臨界值測試
- **異常處理測試**: 錯誤輸入、異常拋出驗證
- **參數化測試**: 多組輸入數據的批量驗證（如適用）
- **Mock/Stub測試**: 外部依賴的隔離測試（如適用）

## 3. 質量標準
- **覆蓋率**: 力爭達到核心邏輯80%以上的分支覆蓋
- **獨立性**: 每個測試用例相互獨立，無依賴順序
- **可讀性**: 測試意圖清晰，便於理解和維護
- **可重複性**: 測試結果穩定，多次運行結果一致
- **執行效率**: 測試運行快速，避免不必要的等待

## 4. 格式要求
- 輸出完整可運行的測試代碼
- 每個測試方法添加簡要註釋説明測試目的
- 提供測試執行命令
- 如有Mock需求，提供Mock配置代碼

## 5. 風格約束
- **代碼風格**: 遵循對應語言的編碼規範（如PEP8、Google Style等）
- **註釋語言**: 中文註釋説明測試意圖
- **專業程度**: 適合中級開發者閲讀和維護

# 質量檢查清單

在完成輸出後，請自我檢查:
- [ ] 測試用例是否覆蓋了所有公共方法
- [ ] 是否包含正常路徑和異常路徑測試
- [ ] 邊界條件是否得到充分驗證
- [ ] 測試命名是否清晰表達測試意圖
- [ ] Mock/Stub使用是否合理
- [ ] 測試代碼是否可以直接運行
- [ ] 是否提供了測試執行説明

# 注意事項
- 不要測試語言內置功能或第三方庫的正確性
- 避免測試私有方法（除非有特殊需求）
- 測試數據應具有代表性，避免過於簡單或過於複雜
- 對於有外部依賴的代碼，優先使用Mock隔離
- 異步代碼需要使用對應的異步測試方法

# 輸出格式
請按以下順序輸出:
1. 📊 **測試策略概述**: 簡要説明測試設計思路
2. 📝 **完整測試代碼**: 可直接運行的測試文件
3. 🔧 **執行説明**: 測試運行命令和依賴安裝
4. 📈 **覆蓋率分析**: 測試覆蓋的功能點清單
5. 💡 **優化建議**: 代碼質量或可測試性改進建議（如有）

實戰：從“不敢動”到“隨便改”

口説無憑，我們來看一個真實的Python案例。

場景：你寫了一個郵箱驗證函數 validate_email，邏輯看起來很簡單：要有 @，要有 .，不能為空。

但是，當你把這段代碼交給AI，並使用上述指令時，它不僅測試了 user@example.com（正常路徑），還狠狠地“刁難”了你的代碼：

• 邊界測試：a@b.c（最短有效郵箱）
• 異常測試：傳入 None 或 123（非字符串輸入）
• 特殊字符：user.name+tag@example.com（合法但少見）

AI生成的測試代碼會包含這樣的參數化測試，把所有可能性一網打盡：

    @pytest.mark.parametrize("invalid_email", [
        "plainaddress",
        "@missingusername.com",
        "username@.com",
        "username@com",
        "username@-example.com",
    ])
    def test_various_invalid_emails(self, invalid_email):
        """參數化測試: 多種無效郵箱格式"""
        assert validate_email(invalid_email) is False

這就是專業。它替你考慮了那些你可能要在半夜兩點修Bug時才會想到的情況。

3個讓AI寫好測試的“騷操作”

1. Mock一切外部依賴：
   告訴AI：“這個函數調用了數據庫，請用 unittest.mock 把 db.query 隔離掉。” 這樣你的單元測試就不需要連真實的數據庫，跑得飛快。
2. 針對遺留代碼：
   對於那些沒人敢動的“祖傳代碼”，你可以把代碼貼給AI，然後説：“請生成一組特徵測試（Characterization Test），記錄它現在的行為。” 這樣你就得到了一張安全網，保證重構時不會破壞現有邏輯。
3. 測試驅動修復（TDD）：
   發現Bug了？先把復現Bug的條件告訴AI，讓它生成一個會失敗的測試用例。然後你再去修代碼，直到測試變綠。這才是修復Bug的正確姿勢。

寫在最後

單元測試，是工程師給自己的一份職業保險。

它讓你在面對複雜的業務變更時，依然能保持從容；它讓你在週五下午發佈代碼時，依然能期待一個愉快的週末。

不要讓“沒時間”成為藉口。有了這套指令，你離“代碼自信”只差一次複製粘貼。

現在，去給你的核心代碼穿上這件“防彈衣”吧。願你的控制枱，永遠是一片生機盎然的綠色。