昨天請 Codex Review 現有測試，檢查它們是否真的保護使用者行為、是否依賴實作細節，以及哪些高風險情境仍然沒有被覆蓋。

今天要根據 Review 結果補測試。

但目標不是讓測試檔案變長，也不是把覆蓋率推到 100%，而是用最少的案例保護目前最重要、最容易壞掉的行為。

覆蓋率高，代表測試好嗎？

覆蓋率可以告訴我哪些程式行數、分支或函式在測試期間被執行過，卻不能直接證明 assertion 是正確的。

例如測試完成新增任務的操作，卻只檢查送出按鈕仍然存在。新增與儲存邏輯可能都被執行，覆蓋率也會增加，但這個測試沒有確認任務真的出現在畫面上。

另一個極端，是為每一行程式建立測試。數字可能很漂亮，卻產生大量重複案例，讓未來的小幅重構也要修改很多測試。

只測試目前已經存在的功能

目前 Issue Tracker 已完成：

• 顯示空狀態
• 新增任務
• 驗證空白標題
• 清理標題前後空白
• 成功後清空輸入欄位
• 將任務保存到 localStorage
• App 重新建立後讀回任務

編輯、刪除、搜尋、篩選、排序與拖曳尚未實作，因此今天不會為這些功能先寫測試。

測試不存在的需求，往往會迫使 Codex 順便設計未來的 API 或資料模型，反而讓測試超出目前產品範圍。

從風險決定優先順序

我會用三個問題評估測試價值：

1. 這個行為有多重要？
2. 未來修改時有多容易壞掉？
3. 現有測試是否已經能抓到它？

可以先把候選案例整理成：

這些只是候選項目。是否要加入，仍要看昨天的 Review、現有測試與已確認需求。

例如「storage 內容損壞時怎麼處理」如果產品行為還沒決定，就應該先列為待確認，而不是直接由測試替產品做決策。

第一階段：請 Codex 提出測試計畫

我會沿用昨天的測試 Review 任務，先請 Codex 根據 findings 排出優先順序：

請根據剛才確認的測試 Review findings，為目前 Issue Tracker 提出最小測試改善計畫。

目前只處理已經存在的功能：
- 新增任務與標題驗證
- 任務寫入 localStorage
- App 啟動時讀回任務

請不要為尚未實作的編輯、刪除、搜尋、篩選、排序或拖曳建立測試。

對每個候選案例說明：
1. 要保護的使用者行為
2. 沒有這個測試時可能漏掉的 regression
3. 現有測試為什麼沒有涵蓋
4. 建議使用單元、元件或整合層級的理由
5. 預計新增或修改的測試檔案
6. 優先級：高、中或低

請找出重複或低價值案例，並說明為什麼不建議加入。
如果某個案例需要先決定產品行為，請列為待確認，不要自行決定。

這次只提出計畫，不要修改檔案。
最後推薦這一輪最少且必要的測試集合，不以 100% 覆蓋率為目標。

這個 Prompt 不只要求 Codex 列出「可以測什麼」，還要求它說明沒有這個案例會漏掉哪一種 regression。

如果兩個候選測試保護完全相同的失敗，就應該優先留下較接近使用者行為、較不依賴實作細節的那一個。

這段 prompt 的回覆

人工確認測試計畫

Codex 提出計畫後，檢查：

• 每個案例是否對應已存在的需求
• 是否真的補上現有測試的缺口
• 不同案例能否抓到不同錯誤
• 是否從使用者可觀察的結果驗證
• 有沒有寫死 class、元件結構或自動產生的 ID
• 是否會和其他案例共享 localStorage 狀態
• 待確認的產品行為是否被偷偷決定

最後只留下這一輪真正要補的案例，其他項目可以延後或不處理。

第二階段：加入最少且必要的測試

計畫確認後，再讓 Codex 開始修改：

請依照剛才確認的測試改善計畫，加入這一輪核准的最少測試案例。

要求：
- 遵守 AGENTS.md
- 只修改計畫中確認的測試檔案
- 除非測試暴露出真實問題，否則不要修改產品程式
- 不新增套件或變更測試框架
- 從使用者可觀察的行為驗證結果
- 不依賴 CSS class、元件內部 state 或自動產生的 ID
- 每個案例要建立並清理自己的 localStorage 狀態
- 不加入只為提高覆蓋率、卻沒有新風險的 assertion

完成後請執行相關測試與完整測試，並回報：
1. 新增或修改了哪些案例
2. 每個案例保護的行為與 regression
3. 哪些候選案例沒有加入，以及原因
4. 測試指令與結果
5. 是否發現產品程式的真實問題

如果新增測試後出現紅燈，不能立刻把 assertion 改成綠燈。要先判斷是測試假設錯誤、產品行為尚未定義，還是真的發現了缺陷。

今日小結

今天沒有要求 Codex 把每一行程式都測到，而是先從重要性、發生機率與現有缺口評估風險，再加入最少且必要的案例。