最基本的問題：「到底什麼是測試驅動開發？」

我們在 go-tdd-kata 的道場裡，扎實地練習著 FizzBuzz 和字串計算機，將「紅-綠-重構」的節奏刻入指尖，變成了肌肉記憶。體會到了 TDD 帶來的、前所未有的內心安定——那種由全面測試覆蓋所賦予的、敢於對任何程式碼進行重構的強大信心。

那我希望讀者大大們可以好好定義一下 "對你們來說，TDD 是甚麼 ?"

AI 好同事

面對著沒有測試的 Legacy Code，小心翼翼地為它補上「特性測試」，讓 AI 幫助我們開出一條新的路，為後續的維護提供一條安全的道路。

接著，我們提升了開發的維度，我們不再僅僅滿足於「把事情做對」，而是開始追求「做對的事情」。因此我們認識了 ATDD/BDD 和 Gherkin，讓測試成為團隊溝通的「共同語言」，確保我們寫下的每一行程式碼，都精準地對應著一個真實的業務價值。

最後，我們學會了詠唱「Prompt」，指揮 AI 為我們生成測試、實現邏輯、code review、甚至挑戰我們的思維邊界，我們不再是碼農，而是演變成了手握方向盤、指揮 AI 高效施工的工頭。

這三十天，我們所學的，早已超越了 Golang 的語法或某個框架的 API，我們學會的是一套全新的、面向未來的軟體開發的樣貌，因此這是我目前開發下來的心得:

語言從不是開發的重點，重點是你懂怎麼用對的方式把事情做對。

所以在遇到新Task時，我首先問的不再是「我該如何實現它？」，而是：

• 「我該如何驗證它？」(ATDD 思維): 這個需求的驗收標準是什麼？我能否用 Given-When-Then 的方式，把它描述成一個清晰的、可執行的場景？我會先和 PM、QA 透過編寫 .feature 檔案來達成共識。
• 「第一個會失敗的測試是什麼？」(TDD 思維): 在清晰的業務目標下，我會思考最小的實現路徑。我會指揮 AI，為這個最小路徑生成第一個會失敗的單元測試，點亮那盞熟悉的「紅燈」。
• 「AI 能如何加速這個循環？」(AI 協作思維): 在「紅-綠-重構」的每一步，我都思考 AI 能扮演什麼角色。是生成測試樣板？是快速實現邏輯？還是提供重構建議？我主導流程，AI 負責加速。
• 「我的測試是否足夠『壞』？」(健壯性思維): 在功能完成後，我會讓 AI 扮演「駭客」或「QA」，來攻擊我的程式碼，挑戰我沒想到的邊界條件，確保軟體的健壯性。

在普遍的開發中，測試可能是普通工程師在功能完成後「不得不做」的收尾工作；而現在，測試（無論是 ATDD 還是 TDD）已經成為思考的起點、設計的驅動力、重構的安全感，以及與團隊溝通的橋樑。

開發者的價值

AI 會迫使我們將時間和精力，投入到那些更具創造性、更具價值的領域：

• 提出好問題，而不是寫出好答案： 精準地定義問題、拆解需求及設計需求文件，都是最重要的目標。
• 系統化思考與架構設計： 構建模組之間清晰的邊界、設計可擴充的系統架構，這是 AI 短期內無法企及的高度。
• 溝通與協作： 理解業務的痛點，與團隊成員高效協作，領導專案走向成功，這些「軟技能」最終定義了你的價值上限。

完賽感言

希望這段經歷，不僅僅是為技能庫增添了幾項新工具，更能為我們的開發思維，帶來一次深刻的啟發 (希望有哈哈)。

此專案的相關 markdown 及 專案程式碼都放在個人GitHub，走過路過都可以留個星星，若對內容有想法的話也歡迎發個 issue 交流討論。

目前從 0 到 1，已經做到了，就看未來遇到 怎麼應對，努力從 1 到 N 邁進。