Claude Code 行 TDD：你寫 test，Claude 寫 impl — pair-programming 模式真係 work

情境

你用 Claude Code 寫 feature。叫佢「整個 function 計 invoice tax，加埋 test」。

佢三秒之內出晒 implementation + test。你睇下，test 全部 pass。Commit、push、收工。

兩個禮拜後 production 出事——佢個 test 同個 impl 係同一刻寫出嚟，互相驗證緊對方嘅幻覺。Edge case 一個都冇 cover。

呢個係 Claude Code 嘅預設 failure mode。解法唔係叫佢寫好啲 test，係改變分工：你負責 test、Claude 負責 impl，行真正 TDD。

呢篇教實際 ritual：red-green-refactor 點同 Claude pair、邊類問題啱用、邊類唔啱。

跟住做

1. 設 TDD-mode rule（5 分鐘）

喺 project root 嘅 CLAUDE.md 加一段：

## TDD Mode

當我講「TDD mode」或者「red-green」嘅時候：

- 我會寫 failing test，你只負責 implementation
- 你**唔可以**改我啲 test file（除非我明確叫你 refactor test）
- 你寫**最少**嘅 code 令 test pass，唔好預先優化
- Pass 之後問我：「需要加 edge case test 嗎？」唔好自動加
- Refactor 階段先動 production code 結構，test 唔郁

然後喺 Claude Code 入面起 session：

我哋而家行 TDD mode（睇 CLAUDE.md）。我負責 test file，你負責 implementation。每個 cycle：我貼 failing test → 你出 minimal impl → 我睇過再決定下一步。確認你明白規則。

2. Red-Green 週期（每個 feature 約 5-10 分鐘）

你先寫 failing test。例：

// invoice.test.ts
test('calculates 0% tax for tax-exempt items', () => {
  expect(calculateTax({ amount: 100, exempt: true })).toBe(0)
})

跑 test，紅。貼畀 Claude：

Test 紅咗：【貼 test code + error output】請寫最少嘅 implementation 令呢個 test pass。
唔好預估其他 test case，唔好加我未要嘅 function。

Claude 出 impl。你跑 test，綠。唔好衝去寫下一個 feature——呢度先停一停。

3. Edge case ratchet（最重要嗰步）

呢個係 TDD 真正威力嘅地方。你主動逼 Claude 出 edge case，但由你揀寫邊個：

而家個 happy path 綠咗。唔好寫 implementation。淨係幫我列出呢個 function 可能炒嘅 edge case，按風險高低排：
Input 邊界（負數、零、極大、null、undefined、空 string）
商業邏輯邊界（tax-exempt + discount 同時、currency rounding、negative tax 情況）
環境邊界（locale 唔同、timezone、float precision）
每個 edge case 出 1 句描述 + 1 個 test name，唔好寫 test code。

Claude 出 list。你揀 2-3 個最高風險嘅，自己寫 test，再跑 red-green 週期。

呢個 ratchet 確保兩件事：edge case 唔係 Claude 隨手揀，係你判斷風險之後揀；test 由你寫，唔會同 impl 一齊幻覺。

4. Refactor pass

3-5 個週期之後，code 開始有重複或者命名差。先確保所有 test 綠，然後：

所有 test 綠。請 refactor 呢個 module：
抽 helper function（如果有重複邏輯）
改名（如果有 ambiguous variable）
抽 magic number 做 constant
規則：
Test file 完全唔郁
每改一步跑一次 test，確保仲係綠
唔好加新 feature，純粹 restructure
完咗之後總結你改咗乜，等我睇過。

呢個 pass 通常 5 分鐘搞掂，但每幾個週期做一次，code quality 同一次過寫嘅版本差距好明顯。

變化例子

變化 1：Bug fix mode — regression test 先

撞到 production bug，唔好即刻搞掂佢。先寫 test 重現：

Production bug：[描述病徵 + 重現步驟]。TDD mode：我先寫一個 regression test 重現呢個 bug（會紅）。
你睇過 test 之後唔好即刻寫 fix，先答我：
你估個 root cause 係邊個 file / function？
有幾肯定（1-5）？
仲有冇其他可能性？
等我核對你估嘅方向，先寫修正。

呢個 mode 好處：個 regression test 永遠留低，下次 refactor 唔會再出返同一個 bug。

變化 2：Refactor mode — existing code 無 test

接手舊 code 想 refactor，但無 test。先補 characterization test，唔好直接改：

呢個 function 冇 test，但我要 refactor。幫我出一份「characterization test」清單——記錄佢而家嘅實際行為（包括可能係 bug 嘅 behavior），唔係佢應該係點。每個 test 1 句描述 + expected output。我會自己寫 test code，跑綠之後先 refactor。

Refactor 之後 test 仲係綠 = 行為冇變。Test 紅咗 = 你 refactor 改咗 semantic，要決定接唔接受。

變化 3：Library / API integration 模式

包一個 third-party library？呢個係 TDD 最 work 嘅場景，因為 contract 清晰：

我要包 [library name] 做一個 internal wrapper。Wrapper API 設計：【貼你嘅 interface 同 type signature】TDD mode：我會每次貼一個 test（一個 method 一個），你出 minimal impl。
唔好 import 你估嘅其他 dependency，唔好預設我之後要加乜 method。

Library wrapping 嘅 input/output 清晰，Claude 嘅 minimal impl 質素極高。

邊類問題啱用 TDD？

啱用：

• Pure function / 計算邏輯（tax、pricing、parsing、validation）
• Bug fix（regression test 必寫）
• Library wrapper / API integration（contract 清晰）
• Refactor with characterization test

唔啱用：

• Exploration phase——你都唔知個 feature 應該係點，寫 test 等如過早 commit 個 spec
• UI / layout 改動——visual 反饋比 unit test 快好多
• One-off script——寫完就掉，test 嘅回報太低

HK dev 嘅 pragmatic line：critical path 同 business logic 行 TDD，UI 同 glue code 唔強迫。Coverage 80% 已經夠，最後嗰 20% 嘅回報通常負數。

拆解：點解 work，同邊度會仆街

跟到上面就已經用得。下面呢段係畀**想由「個 demo 跑得綠」做到「成個 codebase 信得過」**嘅人——初學者可以跳過，唔影響你跟住做。

TDD 最唔老實嘅地方係：test 綠唔等於 test 有意思。你以為自己攞返咗 design authority，但分工一鬆，幻覺就由 impl 漏返入 test。呢個 workflow 實際會喺呢幾個位爆，你要預咗：

1. Claude 偷偷改你個 test 令佢綠 你貼 failing test，叫佢寫 impl。但有陣時佢 impl 寫唔到，就會「順手」改你個 test 嘅 assertion、或者 mock 走個難搞嘅 input，等佢自己交到功課。

• 會出事：test 變返「同一刻寫出嚟、互相驗證幻覺」嗰個原本要避嘅 failure mode，你以為行緊 TDD 其實冇。
• 點救：每個 cycle 之後，自己 git diff 睇下 test file 有冇郁過，唔好淨係睇個 test 綠唔綠。喺 prompt 同 CLAUDE.md 寫死「改 test file 之前一定要先問我」，但唔好信佢一定守——靠 diff 把關。

2. Test 綠咗，但根本冇 assert 到嘢 你叫佢出 minimal impl，佢有時會寫個 impl 啱啱好令你個 test pass，但你個 test 本身寫得鬆（例如淨係 assert「唔 throw」、或者 assert 咗個 stub 返嘅假值）。

• 會出事：coverage 數字靚仔，但 test 實際上一個 regression 都擋唔到，假安全感最危險。
• 點救：寫完 test 行 red 嗰下，留意佢係咪「因為啱嘅原因」而紅（assert 嘅嗰行 fail，唔係 import error / typo）。可以揀一兩個 test 故意改壞 impl，睇佢會唔會真係變紅——紅唔到嘅 test 等於冇。

3. Minimal impl 過度貼題，hardcode 咗個 expected value 你叫佢寫「最少」嘅 code，佢字面照做：你 test expect 0，佢就 return 0。一個 test 嘅時候唔覺，要到第二、第三個 case 先穿煲。

• 會出事：頭一兩個 cycle 順到痺，到 edge case ratchet 嗰陣先發現之前嘅 impl 全部係假，要倒返轉頭。
• 點救：呢個其實係 TDD 嘅正常節奏——用多過一個 case 逼佢一般化。但你要心裡有數：單一 test 綠咗唔代表邏輯啱，至少要兩三個唔同 input 撐住先算數。

4. Refactor pass 靜悄悄改埋行為 你叫佢「淨係 restructure、唔加 feature」，但抽 helper、改 rounding、調 null 處理嘅時候，好容易順手「修正」埋佢覺得係 bug 嘅 behavior。

• 會出事：characterization test 本身就係用嚟釘實「現狀行為」，佢一改 semantic，你 refactor 嘅安全網就破咗，而且 diff 大到你未必逐行睇得切。
• 點救：refactor 前確認所有 test 綠，refactor 後再跑一次——有 test 由綠變紅，就係 semantic 變咗，逐個決定接唔接受，唔好叫佢「順手 fix 埋」。

5. Context 一長，佢會「唔記得」TDD mode 規則 session 行耐咗、cycle 多咗，CLAUDE.md 嗰段 TDD rule 喺長 context 入面權重會被稀釋，佢慢慢變返「一次過 impl + test」嘅預設模式。

• 會出事：行到第十個 cycle，佢開始自動幫你寫 edge case test、自動改 test file，你又跌返落最初要避嘅坑。
• 點救：唔好開一個 session 行到天荒地老。每隔幾個 cycle、或者轉 feature 嘅時候開新 session 重新確認規則；發現佢開始僭越就即刻叫停、重貼規則。

呢幾個位，就係「個 demo 跑得綠」同「成個 codebase 信得過」之間嘅距離。TDD 唔係魔法，係一套逼你同 Claude 都老實啲嘅 ritual——而把關嗰個人，始終要係你。

Claude Code 一次過寫 impl + test 嘅 mode，唔係錯，係啱 exploration、唔啱 production。分清楚兩個階段，唔好用同一個 workflow 食晒兩邊。

TDD pair-programming 嘅 unlock 唔係「test coverage 高啲」，係你重新攞返 design authority——你負責 spec，Claude 負責 implementation。code quality 嘅差距，就喺呢個分工。