Logo
Published on

AI 時代，TDD 不是過時了，而是更重要了

Testing AI

測試系列文章

開發者：「AI，幫我寫一個購物車功能」 AI：「好的，這是完整的實作」(可能是超過 500 行程式碼) 開發者：「… 這程式碼對嗎？我該從哪裡開始理解？」

這個場景你一定不陌生。AI 能瞬間產出大量程式碼，但你真的掌控了嗎？

AI Coding 的三個問題

AI 能快速產生程式碼的時代，開發者面臨了三個新的挑戰

第一是過度實作。你只是要一個簡單的 CRUD，AI 卻給你一整套 DDD 架構。你只是想要一個計算功能，它卻幫你建好了 Strategy Pattern、Factory Pattern，外加一個抽象層。不是說這些設計不好，而是在這個階段你根本不需要

第二是脆弱性。AI 產生的程式碼看起來能動，但當你要加新功能或改需求時，改 A 壞 B 的情況會變得更頻繁。因為你不理解程式碼之間的依賴關係，每次修改都像在拆彈

第三是理解斷層。程式碼可以運作，但你不知道為什麼要這樣寫。不知道為什麼要這樣設計、看不懂某些抽象化的必要性、當需要修改時不知道從哪裡下手。你有了一台運作正常的機器，但不知道它的工作原理，一旦出問題就束手無策

這三個問題最終匯聚成一個感受 —— 失控感。你不再握著方向盤，而是坐在副駕看 AI 開車

你還在「開發」軟體嗎？還是只是在「接受」AI 給你的程式碼？

AI 擅長 How，不擅長 What 和 Why

要理解 TDD 在 AI 時代的價值，先要看清楚 AI 的能力邊界

AI 很擅長解決 How (如何實作)。給它一個明確的規格，它可以寫得又快又好。你說「幫我寫一個排序演算法」，它秒出 Quick Sort；你說「幫我實作 JWT 驗證」，它整套流程都幫你搞定

但 AI 不擅長 What 和 Why。What 是「範圍」—— 你到底要做到什麼程度？Why 是「設計意圖」—— 為什麼要這樣設計而不是那樣設計？

當你跟 AI 說「幫我寫一個購物車功能」，它不知道你的購物車需要支援到什麼程度。要不要處理優惠券？要不要支援多幣別？庫存檢查要做到什麼程度？AI 沒有辦法替你做這些決定，它只能猜，而猜的結果通常是「全部都做」，這就是過度設計的根源

TDD 的本質：不是先寫測試，而是用測試驅動設計

在談 TDD 怎麼跟 AI 搭配之前，先回到一個更根本的問題：TDD 到底在做什麼？

多數人聽到 TDD，第一個想到的是「先寫測試，後寫程式碼」，就是紅燈、綠燈、重構的循環。但這只是 TDD 的表象

Kent Beck 在 “Test Driven Development: By Example” (測試驅動開發：案例導向的逐步解決之道) 中表達了一個更深層的觀點：測試不只是為了驗證程式碼正確性，而是為了驅動設計決策。透過測試「發現」設計，而非事先「規劃」設計

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

所以 TDD 的核心價值，不在於驗證程式碼對不對，而在於幫你想清楚該怎麼設計

TDD 的三個層次

我把 TDD 的理解分為三個層次

第一層：技術執行 (What) —— 你知道要先寫測試、知道紅燈綠燈重構的流程，就只是照著做。比如網球計分的第一個測試 test('0-0 should return love all')。很多人都會，但這只是 TDD 的表面

第二層：設計驅動 (How) —— 測試強迫你思考 API 介面、引導你做出小而專注的設計決策、幫助你發現領域概念和抽象。當你寫測試的時候，你會發現「我需要一個 score() 方法，那這個方法應該接收什麼參數？應該回傳什麼？」測試在你寫產品程式碼之前，就幫你設計好 API 的形狀

第三層：思維模式 (Why) —— TDD 是一種「對話式設計」的思維方式。透過測試與需求對話、與設計對話、與未來對話。以已知為錨，探索未知，並把未知化為已知

用第三層的思維來看：先跟需求對話，用測試把要的行為說清楚，同時劃出現在不要做的範圍；再跟設計對話，從紅燈到綠燈只做讓測試通過的最小改動，讓好的介面和抽象自己長出來；最後跟未來對話，這些測試會留下可被信任的文件與安全網。每一次綠燈，都是把一塊不確定變成可被信任的確定

為什麼 AI Agent 更需要 TDD

搞清楚 TDD 的本質之後，再來看 AI Agent 時代

傳統開發中，TDD 幫你設計程式碼、給你重構的信心、留下活文件。這些好處不會因為 AI 出現就消失。但在 AI Agent 時代，TDD 多了兩個以前沒有那麼明顯的價值

控制 AI 的實作範圍。透過測試，你定義了「只要做到這樣就好」。不要過度設計，不要做多餘的功能。這正好解決了 AI 過度實作的問題

引導 AI 的方向。注意是「引導」，不是「限制」。我們不是在限制 AI 的能力，而是在給它一個明確的方向。AI 擅長 How，那我們就用測試來定義 What，讓 AI 專注在它擅長的事情上

一個核心問題：先寫測試還有意義嗎？

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

有人會說「當然有意義，這是 TDD 的核心，先寫測試這個順序不能改，改了就不是 TDD 了」。也有人會說「測試和實作的產出方式變了，但 TDD 的精神沒變」

讓我們更深入思考：如果讓 AI 先把所有測試寫完，算不算 TDD？答案是不算。在前面的文章中，我們花了不少篇幅區分 Test-All-First 和 TDD 的差異——一口氣寫完所有測試再實作，本質上就是 Test-All-First。不管是人寫的還是 AI 寫的，只要跳過了「一次只處理一個行為」的節奏，那個透過測試逐步探索和發現設計的過程就不見了

Kent Beck 說 TDD 像對話，你問一個問題，程式碼回答你，你再決定下一步。一次問十個問題，就失去了對話的節奏。讓 AI 一口氣寫完所有測試，跟你自己一口氣寫完所有測試，問題是一樣的

我的觀點是：AI 時代，順序和節奏都重要，但實踐方式可以更彈性。關鍵不只是測試寫在前面，而是開發者有沒有參與每一步的設計思考。人類主導還是被動接受，這才是真正的分界線

不同模式下的 TDD 實踐

AI Coding 的演進大致可以分成幾個階段：Copilot 模式 (AI 補全程式碼)、Composer/Edit 模式 (AI 跨檔案完成任務)、AI Agent 模式 (AI 全自動完成)。每個階段適合的 TDD 實踐方式不太一樣

在 Copilot 和 Composer/Edit 模式下，開發者還是主導的一方，AI 只是輔助。這種情況比較適合原本的 TDD 流程 —— 你寫測試，AI 幫你補全或實作

在 AI Agent 模式下，有兩種做法可以選擇

做法 A：維持 TDD 節奏。你定義一個行為 → AI 寫一個測試 → 你 Review → AI 實作 → 你 Review → 下一個行為。節奏慢一點，但保持了 TDD 小步前進的精神。每一輪你都在參與設計決策，AI 只是加速執行的那雙手

做法 B：務實的 Test-First + Review。讓 AI 一口氣完成所有測試，你 Review 測試設計，確認涵蓋範圍有沒有過度或不足，然後讓 AI 實作。老實說，這比較接近 Test-First 而不是嚴格的 TDD，因為你犧牲了小步前進的回饋循環，換取的是速度。在需求明確、設計空間不大的場景下，這是務實的選擇

兩種做法沒有絕對的對錯。需求模糊、設計複雜的時候，做法 A 讓你更安心；需求明確、想快速推進的時候，做法 B 更實際。重點是你要知道自己選的是哪一種，以及你犧牲了什麼

不管是哪種模式，TDD 的精神不變 —— 用測試驅動思考，只是執行方式更彈性。只要你還在介入、還在理解，你就還握著方向盤

前置步驟不能省

不管有沒有 AI，TDD 的起點不是寫測試，而是先想清楚「要測什麼」。從一個需求出發，把可以驗證的行為探討出來，並整理成 TDD 的測試案例。這個過程其實就是 Specification by Example (SBE) 的核心精神 —— 用具體的例子定義需求。這是思考與設計的一部分，也是實踐 TDD 的關鍵環節

比如你拿到一個需求「實作網球計分系統」，你不是直接開始寫測試，而是要先思考：最簡單的測試案例是什麼？ (0-0 → “love all”) 下一個測試案例是什麼？ (1-0 → “fifteen love”) 這個思考過程，就是在拆解需求和規劃測試路徑

這一步決定了 TDD 之後所驅動的設計走向。如果你的測試案例選得不好，TDD 就變成形式主義；如果選得好，TDD 就能發揮威力。AI 可以幫你加速實作，但這個思考的過程不能被跳過

該做的事情還是要做

AI 出來之後，我常說一句話：該做的事情還是要做，它沒有不見

沒有 TDD 的幫助，你還是要想辦法解決那些問題 —— 控制範圍、理解設計、防止迴歸。只是現在，工具和方法可能變了

AI 的演進改變了 TDD 的實踐方式，迫使我們重新想清楚哪些是核心、哪些可以調整。但 TDD 的本質 —— 用測試驅動思考 —— 這件事沒有變

TDD 在 AI 時代的新定義

走到這裡，我想用一句話總結我對 TDD 在 AI 時代的看法

TDD 從來不只是「先寫測試」的機械流程。它是一種用測試保持思考的習慣，讓你在 AI 高速產出的節奏裡，不會丟掉對設計的理解

AI 給了我們速度，TDD 給了我們掌控。少了任何一邊，都走不遠

圖片來源：AI 產生