JIT Test File Lifecycle Management

概念概覽

核心矛盾

核心知識

核心矛盾

JIT（Just-In-Time）測試的設計初衷是**針對特定情境的一次性驗證**。若測試檔案命名為 JITTEST_xxx_test.go 卻永久留存於 codebase，命名本身就成了矛盾——它既不是 just-in-time，也沒有 lifecycle 管理。

決策框架

測試完成後 → 這個測試有長期重複執行的意義嗎？
    ├── 有 → 改名為描述性名稱（dungeon_edge_cases_test.go）
    └── 沒有 → 刪除，不進入 git history

判斷標準

• 改名保留：覆蓋特定 edge case 邏輯、未來 refactor 時仍有防護意義
• 測完刪除：只是驗證某次 hotfix 修正後行為正確、或一次性壓測數據蒐集

與 Meta JIT Catching Test 的關係

Meta 的 JIT catching test 是另一個層次——**自動生成**測試而非手動撰寫。Meta 方案面對的問題是 API 模式生成品質差（編譯失敗、測錯東西），這需要外部 assessor 來降噪，而非只是命名治理。

經驗教訓

• JITTEST 命名的問題不只是整潔性，而是它模糊了「臨時驗證」與「長期回歸保護」之間的邊界

• 審查現有 JITTEST 檔案時，應問「這個 test 如果明天 CI 跑失敗，我會去修它嗎？」——答案是否的話就刪除

常見陷阱

• 因為「以後可能有用」而保留 JITTEST 檔案，最終累積大量無人維護的測試，CI 失敗時沒人知道該修還是刪

最佳實踐

• 為 JITTEST 建立 PR checklist：每個 JITTEST 檔案在合併前必須決定改名或刪除

• 不允許 JITTEST 命名的檔案進入 main branch

相關概念

• Argo Events Ephemeral Pod JIT Test Architecture
• Go Test Coverage -coverpkg Flag
• Hero Unlock Idempotency
• Testcontainers Custom PostgreSQL Image

來源 Sessions

日期	Session	貢獻摘要

| 2026-03-24 | cc0870e9-96f8-44f2-8716-4d11484f8a36 | 確立 JITTEST 命名慣例的哲學問題：JIT 語意本身是一次性，永久留存於 codebase 是矛盾的 |

---

本概念頁面由 Semi-Brain Wiki 系統自動維護

最後更新: 2026-03-24