鐵人檔案
AI coding agent 能快速產生大量測試，但「這個測試值不值得留、覆蓋夠不夠、重構要不要做」這些品質判斷不能交給 AI 自己決定。這系列用「留不留、夠不夠、做不做」三個判斷貫穿全程，拆解 AI 寫測試最容易犯的錯（硬編碼、過度 Mock、只測 happy path、Test Double 選錯種類），以及怎麼讓 AI 真正遵守 Red-Green-Refactor 循環，而不是把整個循環壓縮成一次產出。
前言 「AI 都已經能自動生成測試了，還需要學 TDD 嗎？」 這大概是我這幾年被問過最多次的問題之一。表面上聽起來很合理：以前寫測試要花時間，現在跟 AI c...
前言：三個步驟大家都會背，但真的知道每一步在防什麼嗎？ 「Red-Green-Refactor 誰不知道？寫一個失敗的測試、讓它通過、再重構，這種基本功還需要花...
前言：測試都通過了，為什麼還要懷疑？ 「AI 幾秒鐘就能幫你的函式產生一整套測試，語法正確、結構完整、跑起來全部綠燈——這樣還不夠好嗎？」 這句話聽起來很合理，...
前言：測試都通過了，為什麼還要懷疑？ 「AI 幫這個方法寫了三個測試，全部綠燈，這樣應該可以放心合併了吧？」 這句話聽起來很合理——測試通過本來就是我們判斷「這...
前言：綠燈不等於「測到了」 「這個測試是綠的，代表這段邏輯是對的吧？」 Day 04 講過一個具體案例：AI 生成的測試全綠，卻沒測到任何有意義的行為。今天要把...
前言：測試從沒紅過，你怎麼知道它會抓到問題？ 「反正最後測試都是綠的，中間有沒有真的紅過一次，有差嗎？」 有差，而且差別很大。昨天講完假陽性測試的三種樣貌——空...
前言：檢查有沒有寫測試，是最容易被騙過的一種檢查 「這個 PR 有沒有寫測試？」這句話幾乎是每個團隊 code review 時的標準問句。它很好回答——打開檔...
前言：「用最少的程式碼讓測試通過」，這句話不是每個人聽起來都一樣 「Kent Beck 自己都說了，Green 階段就是要用最簡單的方式讓測試通過，AI 這樣做...
