自製 Thread 發文機器人 - TDD
昨天講完 BDD，今天來談談在與 AI 討論完可執行的文件 (Executable Specs) 後，該如何確保 AI 能夠持續在正確的道路上開發。這時候，我們就需要搭配 TDD (Test-Driven Development，測試驅動開發)。
什麼是測試程式碼？
測試程式碼是一段獨立於主體程式的存在。 傳統開發流程通常在主體程式開發完成後才撰寫測試，但常遇到兩個問題：
- 難以測試：寫測試時才發現主體程式根本無法測試（需要重構）。
- 耦合過重：模組沒有切分乾淨，想測 A 卻被迫連著 B 和 C 一起測。
TDD 的核心概念
TDD 的概念由「紅燈、綠燈、重構」組成，核心是讓測試與主體程式同步開發，甚或在寫主程式之前先寫測試。 這能強迫我們提早規劃「最小可測試的實作」，像積木一樣慢慢堆疊出最後的主程式。
流程如下：
- 🔴 紅燈 (Red)：寫一個會失敗的測試（因為功能還沒寫）。
- 🟢 綠燈 (Green)：撰寫最少量的程式碼讓測試通過。
- 🔵 重構 (Refactor)：在保持測試通過的前提下，優化程式碼結構。
測試考慮的情況越多，就越不用擔心之後新增功能時弄壞已有的功能。
AI 時代下的 TDD 優勢
在 AI 時代，TDD 有一個更顯著的好處：將需求拆解成極小的單位。
Vibe Coding 有點像是讓 AI 猜你心中的想法。如果你讓它一次猜太多，每個步驟的微小誤差疊加起來，最後偏離的誤差就會被放大很多，且過程中缺乏檢驗手段（頂多只能做到一半停下來看）。
現在 AI 產出程式碼的成本大幅降低，為了解放我們的注意力，我們應讓 AI 「一次只猜一點點」。
透過 BDD 產生的 Gherkin 需求文件，我們能讓 AI 明確知道自己「做對了沒」。相較於單純使用 Plan Mode 或是讓 AI 產生 Task List，這種方式能讓 AI 的產出更加穩定且可靠。