昨天先建立了一個會失敗的測試，再請 Codex 完成瀏覽器持久化，讓同一個測試從紅燈變成綠燈。

這已經比修完功能才補測試多了一層證據，但測試通過仍然不代表測試品質一定足夠。

今天不修改功能，也不急著補更多案例，而是單獨 Review Codex 寫下的測試。

綠燈代表什麼？

測試顯示綠燈，只能直接證明：目前這份程式通過目前這組測試。

它不一定代表：

• 所有需求都已經被覆蓋
• assertion 驗證的是重要結果
• 測試失敗時能指出真正問題
• 測試不會因重構就無故壞掉
• 測試彼此之間沒有共享狀態

產品程式可能寫錯，測試本身也可能寫錯。甚至兩邊採用相同的錯誤假設時，測試仍然可能通過。

先確定測試在保護什麼

這次最重要的使用者行為是：

新增任務後重新整理頁面，剛才的任務仍然會出現在清單中。

一個偏向使用者行為的測試，應該操作輸入欄位與送出按鈕，重新建立 App，再從畫面確認任務存在。

如果測試只檢查 localStorage.setItem 有沒有被呼叫，就只能證明某個內部 API 被使用，不能證明重新載入後真的能把資料讀回並顯示。

前者保護產品行為，後者則容易和目前實作方式綁在一起。

什麼是過度依賴實作細節？

測試需要知道一部分程式結構，但不應依賴使用者根本看不到的細節。

常見例子包括：

• 直接呼叫元件內部函式
• 檢查 React state 的內容
• 斷言某個函式剛好被呼叫幾次
• 依賴 CSS class 或元件樹層級尋找元素
• 寫死自動產生的任務 ID
• 把 localStorage 的 JSON 排版當成產品需求

如果未來把儲存邏輯移到 custom hook，但使用者行為完全沒有改變，這些測試可能仍然失敗。

比較穩定的做法，是使用 label、role、可見文字等使用者能辨認的方式操作畫面，再驗證可觀察結果。

開一個新的 Codex 任務做測試 Review

我會開一個新的 Codex 任務，避免它延續昨天「這是我剛寫完的測試」的立場。

今天使用的 Prompt 是：

目標：
請審查 Issue Tracker 最新「fix bug」commit 中新增或修改的測試，判斷它們是否能保護任務持久化行為。

請先確認正確的 commit 與 diff 範圍，再閱讀：
- 持久化需求
- 該 commit 的測試變更
- 測試所涵蓋的產品程式
- 現有測試設定
- AGENTS.md

請檢查：
1. 測試名稱、操作步驟與 assertion 是否一致
2. 是否真的模擬 App 被移除後重新建立
3. 是否從畫面驗證任務被讀回，而不只檢查 localStorage API
4. 測試是否在每個案例前建立乾淨的 localStorage 狀態
5. 是否過度依賴函式呼叫、CSS class、元件結構或其他實作細節
6. mock 或假資料是否可能掩蓋真實問題
7. 哪些高風險行為仍未被測試
8. 是否有重複、無法提供額外信心的 assertion

另外請用 mutation 思維回答：
- 如果移除「寫入 localStorage」的程式，哪些測試應該失敗？
- 如果移除「啟動時讀回資料」的程式，哪些測試應該失敗？
- 如果不清除測試之間的 localStorage，是否可能得到假成功或不穩定結果？

輸出規則：
- 先回報具體 findings，依高、中、低嚴重度排列
- 每項附上測試檔案位置、影響與改善方向
- 區分「確認有問題」與「建議補強」
- 如果沒有具體問題，請直接說明
- 最後列出最少且必要的測試改善清單

限制：
- 這次只做 Review，不要修改任何檔案
- 不要為了追求覆蓋率而建議大量低價值測試

怎麼判斷 Codex 的 finding？

Codex 回報的測試問題仍然要人工確認：

• 它指出的測試和 assertion 是否真的存在
• 測試是否已由其他案例間接覆蓋
• 所謂實作細節是否其實是明確需求
• 建議的新案例是否能抓到不同的失敗
• 問題屬於正確性、穩定性，還是單純偏好

我會把結果整理成：

如果兩個測試會因為完全相同的程式錯誤而失敗，第二個案例不一定能增加多少信心。測試數量不是唯一目標。

今天不直接修改測試

這次 Prompt 只要求 Review，讓 findings 先和程式變更分開。

確認哪些問題真的值得處理後，明天再把改善清單交給 Codex，要求它用最少的測試保護最高風險的行為。

這也能避免 Codex 一邊 Review 自己的測試，一邊加入大量 assertion，最後只剩下一個更長、卻沒有更可靠的測試檔案。

今日小結

今天沒有只看測試全部通過，就直接相信 Codex 寫出的案例。