TDD：很多人都搞錯的那個綠燈

今天來分享 TDD，Test-Driven Development，測試驅動開發。

大家可能多少聽過，知道它有三個步驟：紅燈、綠燈、Refactor。但我發現很多人——包括以前的我——對這三步其實有個根本的誤解，特別是在綠燈這一步。

在說三步之前，先說一下為什麼需要 TDD。

傳統的開發流程通常是：先把功能做出來，然後跑跑看、測測看有沒有問題。這樣做沒什麼大問題，但有一個隱患——你不確定你的測試到底在測什麼。

因為你是在功能做完之後才寫測試，潛意識裡測試很容易就配合現有的代碼來寫，而不是真的在驗證行為本身。更常見的情況是根本沒有測試，全靠手動點點看。這樣的代碼改起來很心虛，因為你不知道改了這裡會不會壞掉別的地方。

TDD 翻轉了這個順序：先定義行為，再寫代碼。測試變成需求的描述，不是代碼的附屬品。這樣你在重構或改功能的時候，測試就是你的安全網。

先快速說一下三步是什麼：

紅燈是先寫測試，因為功能還沒做，測試一定失敗，所以是紅的。這步強迫你在動手之前先想清楚「我要做的東西應該要有什麼行為」。

Refactor 就是整理，讓測試通過之後回頭把代碼整理乾淨。

那綠燈是什麼？

很多人會以為：綠燈就是把功能寫出來，讓測試過。對，但有個關鍵很多人跳過了——

綠燈的規則是：只要讓測試通過就好，方法不限，哪怕是最爛的方式。

舉個例子，假設你的測試在驗證一個加法函式，add(1, 2) 要回傳 3。合法的綠燈做法是直接 return 3，hardcode 一個假值。

等等，這不是在騙嗎？

對，這就是 TDD 裡著名的「Fake it till you make it」。你故意先用最簡單、最爛、甚至是假的方式讓測試過。

為什麼？

因為 TDD 要你把兩件事強制分開：

第一件事是確認你的測試設計對不對，你描述行為的方式對不對。 第二件事才是把代碼寫好。

如果你在綠燈就開始想「這個邏輯要怎麼寫才夠優雅」，你就把這兩件事混在一起了，然後就很容易出現一個情況：功能做了很多，但你不確定哪個測試對應到哪個行為，出問題也不知道從哪裡找。

等你綠燈通過，再進 Refactor 的時候，你才把 return 3 換成真正的邏輯，這時候你很清楚你在做什麼——改代碼，不是改行為。改完測試應該還是綠的，如果不是，就是你的 Refactor 改出問題了。

這個節奏一旦跑起來，其實很順。每一步你都非常清楚自己在做什麼，出問題也知道從哪裡找。

當然，實際開發不可能每個 case 都 hardcode 一個假值，很多時候綠燈你就直接把邏輯寫對了，這沒問題。重點是那個「先讓測試過，再去清理」的心態——不要在還沒確認測試通過之前就開始優化。

如果你之前試過 TDD 但覺得很卡，八成是在綠燈就想把代碼寫得太好了。試著放鬆標準，先讓測試過，再慢慢整理，你會發現整個流程順很多。