Tdd | Tarragon

"Tdd"

2026-08-24 判準的推導來源：測試憑什麼不是實作的回音測試與實作由同一次生成或同一輪對話產出時，用來判斷這組測試剩下多少驗證力，以及要動哪個變數才能拿回來
2026-08-19 驗證自己寫對了不確定該測到什麼程度、或是在「這裡到底該不該 mock」上卡住時，用來看清這幾本書彼此不同意在哪的選讀
2026-04-26 Test-First：先看到 RED 才相信 GREEN 一個只看過 GREEN 的測試是「未驗證的訊號」、不是「會抓回歸的測試」。必須先在「該失敗的版本」上看到 RED、再在「該通過的版本」上看到 GREEN — 兩次跑都對、才能相信測試真的 catch 到該 catch 的東西。跳過 RED 等於把驗收標準降到「跑得通」、漏掉「測試自己有沒有 bug」這層。
2026-07-10 產品碼自己是 mock — ViewModel 假實作通過了 15 個測試 ViewModel 用 Future.delayed 加硬編碼資料交付、狀態轉換測試全綠，因為測試耦合的是狀態機、不是業務效果。假實作被當成完成的基礎，直到 63 個測試「寫不出來」才現形——測試的可寫性是實作真實性的探針。
2026-06-23 10 個 Ticket、57 個綠燈、0 條追溯：從需求文件到測試的銜接檢討單元測試全綠、卻對應不出「這些測試覆蓋了哪些 UseCase 場景」。需求到測試缺反向追溯時的流程缺口盤點與對應修法（追溯矩陣、存根策略、拆分規則）。
2026-04-26 Cards-Skills 系統的活案例：從一個 search bug 到 14 張新卡的閉環 report 卡片 + skill 作為自我修正的活知識庫：從一個 search bug 走完閉環的 case study。教訓：test 過不等於對齊意圖、dogfooding 失敗靠外部提問現形、修 bug 是 case study 起點。
2026-03-04 BDD 測試：測行為，不測實作細節替換一個實作就要跟著改掉大批測試、而業務邏輯根本沒動時，用來判斷哪一層該用 Given-When-Then、Mock 的邊界畫在哪裡
2026-03-04 Ticket 設計決策集中在 Phase 3a TDD 階段與 Ticket 系統各走各的、實作到一半才發現手上的任務包含三件事時，用來決定拆分判斷該在哪個階段做、依據哪套標準
2026-03-04 行為優先的 TDD：測試耦合行為、不耦合結構重構時測試大量壞掉、或在「該不該 mock 這個協作者」上需要一個可執行的立場時，本站對兩派 TDD 分歧的選擇與推導
2026-02-02 Ticket 生命週期流程 - AI 協作開發的任務管理系統定義 Ticket 從建立到完成的完整生命週期，包含狀態管理、驗收流程、任務鏈設計和與 TDD 流程的整合