Logo
Published on

AI Coding 下的 TDD 實踐

TDDAI-Coding

引言：當 AI 會寫測試，TDD 還是 TDD 嗎

在 AI Coding 快速發展的今天，我們面臨一個前所未有的挑戰：當 AI 可以同時產生測試和實作程式碼時，傳統的 TDD（Test-Driven Development，測試驅動開發）實踐還有意義嗎？這不僅是一個技術問題，更是關於開發者角色定位的根本性思考

讓我們從一個真實場景開始探討這個問題

AI Coding 帶來的挑戰

真實場景：失控的 500 行程式碼

想像這樣的情境：你打開 AI 助手，輸入「幫我寫一個 XX 功能」，AI 熱情地回應「好的，這是完整的實作...」，然後螢幕上出現了 500 行程式碼

此時你心中浮現兩個問題：

  • 這程式碼對嗎？
  • 我該從哪裡開始理解？

AI 確實能快速產生程式碼，但我們真的掌控了嗎？

三大核心問題

在實際使用 AI Coding 的過程中，我們會遇到三個主要問題

1. 過度實作與過度設計

你只是想要一個簡單的功能，AI 卻常常過度設計。就像你只想煎個蛋，結果 AI 幫你設計了一整套米其林三星的廚房設備

2. 程式碼脆弱性

當你想加新功能或改需求時，可能會遇到「改 A 壞 B」的情況。因為你不理解整個系統的結構，不知道哪些地方有耦合、哪些地方有依賴。就像疊積木，你不知道哪一塊是關鍵，隨便抽一塊，整個都垮了

3. 理解斷層

最可怕的是這個：程式碼能跑，測試也過了，看起來一切正常。但你完全不知道為什麼要用這個 Pattern，為什麼要這樣設計。結果就是——你不敢改

核心感受：失控感

這三個問題累積起來，產生了一種強烈的感受——失控感

我們開始懷疑：還在「開發」軟體嗎？還是只是在「搬運」AI 產生的程式碼？如果我們失去了對程式碼的掌控，我們就不再是工程師，而變成了 AI 的操作員

AI Coding 的演進歷程

要理解當前的困境，我們需要了解 AI Coding 是如何演進到今天這個階段的

Copilot 模式：人類主導

在這個階段，開發者在寫程式碼，AI 在旁邊幫忙補完。人類還是主導者，AI 只是加速器。這個階段，人類完全掌控開發流程

Composer/Edit 模式：部分授權

這時候人類開始給 AI 簡單任務，比如「幫我重構這個 function」、「幫我寫這個 API endpoint」。AI 可以跨檔案完成任務。人類開始部分授權，但仍保有決策權

AI Agent 模式：全自動完成

這就是現在的狀態。人類只要給需求，AI 可以全自動完成。從設計、實作到測試，一條龍服務。在這個階段，AI 幾乎可以完全自主

聚焦 AI Agent：掌控權的問題

本文主要探討 AI Agent 這個階段，因為在這個階段，「掌控權」的問題最為嚴重。當 AI 可以一次產生完整的系統時，傳統的 TDD 實踐還適用嗎？

TDD 的本質探討

要回答這個問題，我們必須先搞清楚：TDD 的本質到底是什麼？

多數人眼中的 TDD

當提到 TDD，大部分人第一個想到的是：「先寫測試，後寫程式碼」。或者用更專業的術語：紅燈（Red）、綠燈（Green）、重構（Refactor）

這個認知沒有錯，但這只是 TDD 的表象

Kent Beck 的核心理念

TDD 的發明者 Kent Beck 提出的核心理念是

測試不是為了驗證程式碼正確性，而是為了驅動設計決策

這句話值得仔細咀嚼。TDD 的重點不是「寫測試」，而是「透過測試來發現設計」。注意這裡用的詞是「發現」設計，而非「規劃」設計

這就像在黑暗中探索一個洞穴，你用手電筒（測試）照亮前方，一步一步發現路徑（設計），而不是在入口就畫好整個洞穴的地圖

從驗證工具到設計工具的轉變

TDD 本質上是一個轉變

  • 從「驗證工具」→「設計工具」
  • 從「事後檢查」→「事前思考」

這個轉變和敏捷宣言的精神很像：不是左邊的沒有價值，而是更在意右邊的

為何 AI Agent 更需要 TDD

理解了 TDD 的本質後，我們需要思考一個關鍵問題：為什麼 AI Agent 時代更需要 TDD？

AI 擅長 How，不擅長 What/Why

AI 很擅長解決「How」（如何實作）的問題。給它一個明確的規格，它可以寫得又快又好

但是，AI 不擅長「What」和「Why」

  • What（範圍）：你到底要做到什麼程度？
  • Why（設計意圖）：為什麼要這樣設計？

這些需要領域知識、設計思維和對業務的理解。而這些，正是 AI 目前還不擅長的

對比範例：直接要求 vs TDD 約束

讓我們看一個具體的對比

❌ 直接要求

給 AI：幫我寫一個網球計分系統
結果：可能會得到一個完整的系統，包含選手管理、比賽記錄、歷史數據、統計分析...

✅ TDD 約束

用 TDD：讓這個測試通過：當比分是 0-0 時，應該回傳 'love all'
結果：AI 只會寫需要的程式碼

看到差別了嗎？TDD 透過測試，幫你定義了「範圍」

TDD 在 AI 時代的新定位

在傳統開發中，TDD 的主要價值是

  • 設計流程和程式碼
  • 提供重構信心
  • 作為文件

但在 AI Agent 時代，TDD 有了新的價值

1. 控制 AI 的實作範圍

透過測試，你定義了「只要做到這樣就好」。不要過度設計，不要做多餘的功能

2. 引導 AI 的方向

注意，是「引導」，不是「限制」。我們不是在限制 AI 的能力，而是在給它一個明確的方向

就像建築藍圖。藍圖不是告訴工人怎麼搬磚，而是定義要蓋什麼樣的房子。工人（AI）可以自由發揮技術，但不會蓋錯方向

TDD 的三個層次

要真正理解 TDD，我們需要知道它有三個層次。很多人只停在第一層，但要發揮 TDD 的威力，需要理解全部三層

第一層：技術執行（What）

這是大家最熟悉的層次：知道要先寫測試，知道紅燈、綠燈、重構

例如你寫

test('0-0 should return "love all"')

這是 What——你知道要寫什麼樣的測試。這一層很多人都會，但這只是 TDD 的表面

第二層：設計驅動（How）

在這一層，測試開始影響你的設計決策

  • 強迫你思考 API 介面該長什麼樣
  • 引導你做出小而專注的設計決策
  • 幫助你發現領域概念和抽象

當你寫測試的時候，你會發現：「喔，我需要一個 score() 方法。那這個方法應該接收什麼參數？應該回傳什麼？」

這是 How——測試驅動了你的 API 設計

很多人寫測試只是為了驗證，但其實測試應該在你寫 production code 之前，就幫你「設計」好 API 的形狀

第三層：思維模式（Why）

這是最深的一層。TDD 是一種「對話式設計」的思維方式

你在透過測試

  • 與需求對話：「這個需求真正要的是什麼？」
  • 與設計對話：「這個設計合理嗎？」
  • 與未來對話：「這個設計好維護嗎？」

這是一種從已知到未知的探索過程

例如你在寫網球計分系統的測試時，你會問自己：「需不需要有 Player 的概念？」

如果你的測試可以不需要 Player 也能跑通，那可能現階段就不需要這個抽象

這就是 Why——你在思考設計的「原因」和「必要性」

測試驅動設計的浮現

完整的 TDD 流程是這樣的

測試 → 驅動設計 → 設計浮現

這個概念叫做「Emergent Design」——設計浮現。意思是設計不是一開始就規劃好的，而是透過測試一步步「發現」出來的，從簡單到複雜的自然演進

你是透過測試「發現」設計，而不是「預先」設計好再寫測試

AI 時代的 TDD 辯證

現在我們面臨一個全場最關鍵的問題

核心問題

如果 AI 能同時產生測試和實作，而且都是正確的，那「先寫測試」這個順序，還有意義嗎？

這個問題在 AI 時代變得很重要。讓我們看看不同的觀點

兩派觀點

傳統派認為：「當然有意義，這是 TDD 的核心！」

他們認為，先寫測試這個順序不能改，改了就不是 TDD 了

實用派認為：「測試和實作的產出方式變了，但 TDD 的精神沒變」

他們認為，重點不是順序，而是精神

AI 先寫測試的問題

如果讓 AI 先寫測試，算不算 TDD？答案是：不完全算

為什麼？因為缺少了「開發者主導」的設計探索

還記得我們說的嗎？TDD 的核心價值是透過測試驅動設計的演進

如果 AI 一次把所有測試都寫完了，那個「探索」和「發現」的過程就不見了。你沒有參與設計的思考，只是被動接受 AI 給你的設計

核心結論：人類主導 vs 被動接受

我的觀點是：在 AI 時代，我們可能不需要完全遵循傳統的 TDD

重點不是先後順序，而是開發者有沒有參與設計思考

讓我再強調一次這個核心觀點

AI 先寫還是後寫，不是關鍵。人類主導還是被動接受，才是關鍵

  • ❌ 被動接受 AI 產生的一切 = 失去掌控
  • ✅ 人類主導設計思考過程 = 保有 TDD 精神

從需求到測試案例的思考

在討論實踐方法之前，我們還有一個關鍵步驟要理解

TDD 的起點是「思考要測什麼」

很多人以為 TDD 的起點是「寫測試」。錯了

TDD 的起點是「思考要測什麼」

從需求探討出測試案例

怎麼從一個需求，探討出 TDD 的測試案例？

這是思考和設計的一部份，也是實踐 TDD 的關鍵環節

比如你拿到一個需求：「實作網球計分系統」

你不是直接開始寫測試，而是要先思考

  • 最簡單的測試案例是什麼？（0-0 → "love all"）
  • 下一個測試案例是什麼？（1-0 → "fifteen love"）
  • 什麼時候需要考慮 deuce？
  • 什麼時候需要考慮 advantage？

這個思考過程，就是在「拆解需求」和「規劃測試路徑」

這個思考過程不能省略

雖然 Kent Beck 在書中，是一邊做一邊推論出來的，看起來很自然

但這個「思考過程」不能省略

其實就跟一般的開發一樣，難道開發前不用討論相關的設計？TDD 也一樣，你需要在開始前，思考測試的策略

這個步驟決定了 TDD 能否真正驅動設計。如果你的測試案例選得不好，TDD 就變成形式主義。如果你的測試案例選得好，TDD 就能發揮威力

實踐方法與建議

在 AI Agent 下如何實踐 TDD？這要分兩種模式來看

Copilot/Composer 模式：傳統 TDD 流程

如果你用的是 Copilot 或 Composer/Edit 模式，那比較簡單

在這些模式下，開發者還是主導，AI 只是輔助。所以你可以比較自然地使用傳統的 TDD 流程

  • 你寫測試
  • AI 幫你補完實作
  • 你 Review
  • 重構

這個流程和傳統 TDD 差不多

AI Agent 模式：新的實踐流程

但如果你用的是 AI Agent，就不太一樣了

我建議的流程是這樣

  • 你先思考測試案例（這是人類做的）
  • 讓 AI 先完成測試
  • 你 Review 測試設計（這很關鍵！）
  • 確認後才讓 AI 實作
  • 你 Review 實作品質

看到重點了嗎？每個階段都要有人的判斷

你不是讓 AI 一路跑到底，而是在關鍵點都要參與、要 Review、要判斷

核心原則：保持掌控

核心原則就是

人工介入 = 保持理解 = 保持掌控

TDD 的精神不變，只是執行方式更彈性

AI 讓我們快，TDD 讓我們穩。兩者結合，才是 AI 時代的正確姿勢

總結與新定義

該做的事情還是要做

該做的事情還是要做，它沒有不見

沒有 TDD 的幫助，你還是要想辦法解決那些問題

  • 過度設計的問題
  • 程式碼脆弱的問題
  • 理解斷層的問題
  • 失控感的問題

只是現在，工具變了

AI 改變了實踐方式，沒有改變本質

AI 演進的過程，改變了 TDD 的實踐方式，但沒有改變 TDD 的本質

TDD 在 AI 時代的新定義

所以，TDD 在 AI 時代的新定義是什麼？

TDD 不是「先寫測試」的機械流程，而是「用測試保持思考」的習慣

TDD 不是為了驅動 AI 的實作，而是為了驅動我們的理解

速度是 AI 給的，掌控是 TDD 給的

最後這句話，我希望你能記住：速度是 AI 給的，掌控是 TDD 給的

AI 讓我們快，TDD 讓我們穩。兩者結合，才是 AI 時代下軟體開發的正確姿勢

支持創作

如果這篇文章對您有幫助，歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力！

圖片來源：AI 產生