Logo
Published on

Classic TDD Workshop — 從混亂到掌控的設計之道

Testing Course

你有沒有過這種經驗？

翻過 Kent Beck 的《Test Driven Development: By Example》(測試驅動開發：案例導向的逐步解決之道)，覺得概念講得很清楚，但書蓋起來打開 IDE，手就停在那裡。第一個測試要寫什麼？測試的順序怎麼排？寫到一半冒出一堆 if/else，最後連自己都看不懂當初想做什麼

或者你試過 TDD，但總覺得哪裡不太對勁。紅燈、綠燈、重構的流程你知道，但每次做起來就是卡卡的，好像照著食譜做菜，味道卻差了一截。你不確定是哪一步出了問題，但就是覺得「應該不只是這樣」

又或者你想學正統的方法論，而不是自己摸索。書讀了、影片也看了，但就是缺少一個機會讓你完整地跑一遍，從頭到尾體驗 TDD 的節奏和手感

如果你對其中任何一個有共鳴，往下看看這堂課在做什麼

在 AI 時代，為什麼更需要學 TDD？

AI Coding 工具可以在幾秒鐘內產出大量程式碼。但產出跟掌控是兩回事

AI 擅長 How——你告訴它要什麼，它很快就能寫出來。但 What 和 Why 是 AI 回答不了的。你到底要做到什麼程度？這段邏輯為什麼要這樣設計而不是那樣設計？這些問題只有你能回答

TDD 的價值就在這裡。它是一種思考方式，不是一種寫測試的技巧

在你動手寫程式碼之前，TDD 先幫你釐清「到底要解決什麼問題」。每一步都有測試保護，你隨時知道自己在哪、下一步要去哪。程式碼也因此變得好維護、好擴展。這種掌控力，在 AI 時代反而變得更稀缺

當 AI 能快速產出程式碼時，能不能判斷這些程式碼是對的、能不能掌控改動的範圍——這些能力反而更值錢

這堂課會帶你走過什麼？

Red → Green → Refactor 核心循環

TDD 最核心的節奏就是紅燈、綠燈、重構。三個步驟看起來直覺，但實際做起來有很多你沒預料到的眉角

什麼是 Baby Step？為什麼每一步都要小到不能再小？因為步伐越小，出錯的時候你越容易找到問題在哪裡。跟在黑暗中用手電筒照路一樣，每次只照一小步，走起來反而最穩

為什麼有時候要「故意」寫出重複的程式碼？因為在 TDD 的世界裡，重複不是壞事——它是重構的燃料。先讓測試通過，看到重複的模式，再消除它。這跟我們平常「一開始就要寫出完美的程式碼」的直覺完全相反

課程中會帶你體驗三種 TDD 的實作方式：假實作 (Fake It)、三角定位法 (Triangulation)、明確實作 (Obvious Implementation)。什麼時候該用哪一種，做過之後你就會有感覺

需求分析與測試案例設計

很多人以為 TDD 的起點是寫測試。不是。TDD 的起點是想清楚「這個需求到底要解決什麼問題」

拿到一個需求之後，你要做的第一件事不是打開 IDE，而是拆解：哪些行為需要被驗證？這些行為可以用什麼樣的測試案例來表達？測試案例之間的順序該怎麼排？

順序這件事比你想的更重要。先做哪一個測試，會直接影響後面的開發節奏。選對了，後面一路順；選錯了，你會卡在半路不知道怎麼往前走。這也是很多人嘗試 TDD 卻覺得「卡卡的」的原因之一——不是 TDD 有問題，是測試案例的順序沒有想好

課程中會帶你練習怎麼從需求出發，建立測試案例清單，然後決定最佳的執行順序

重構的藝術

寫測試讓你有信心，重構讓程式碼越來越好。但重構不是想改就改，它有節奏、有方法

什麼時候該動手？什麼時候先忍住？怎麼找出重複的地方再逐步消除，同時確保測試一直維持在綠燈？這些判斷沒辦法光靠讀書學會，要做過才有感覺

好的程式碼讀起來像一段故事，你看得出它在做什麼、為什麼這樣做。重構就是把那些不清楚的部分，一點一點打磨到清楚為止

AI 時代的 TDD 新思維

Classic TDD 的方法論講完之後，這堂課還會往 AI 時代的方向走

AI 產出的程式碼，你怎麼確保它是對的？測試是你的安全網。當需求改變，你怎麼知道改動不會搞壞其他地方？靠的也是測試

課程還會延伸到幾個跟 AI 相關的方向

  • SDD (Spec Driven Development)：規格驅動開發的概念與實作，把 TDD 的精神帶到 AI 時代
  • 講師自己開發的 TDD 學習工具，幫助你在課後持續練習

在 AI Agent 時代，拆解需求和設計這件事沒有不見。工具在變，但該做的事情還是要做

課程怎麼進行？

這是一堂以實作為主的 Workshop，不是坐著聽講的課程

整堂課你會跟著講師完整地跑過 TDD 的流程——需求分析、測試設計、紅燈、綠燈、重構，一路走到底。兩個 Lab 練習讓你實際動手，不只是聽懂而已

TDD 的手感靠練出來的，光看書不夠。你需要實際做過一輪完整的循環，才會知道那個節奏感是什麼

學員怎麼說？

「今天感覺自己和 TDD 突然距離變很近」— rorywang8

「課程真的太多乾貨一時真的說不完（還有彩蛋！之後會拿來當自己的教練）」— rorywang8

「這堂課不只是教怎麼寫 TDD，而是把測試、邏輯跟重構全部都在一起，讓我收穫滿滿」— ashley_qing0821

「沒想到 test case 的順序也是有意義的，講師帶著我們去思考這個測試是為了完成哪一段的邏輯。讓我意識到每一個 test case，其實都是在一步一步把邏輯的行為跟設計推導出來」— ashley_qing0821

「在過程中可以聽到書上沒有提到的細節和思考方式，讓我能回頭檢視自己之前練習時卡的地方」— 郭柏均

「CP 值非常高，內容很超值」— 郭柏均

「沒想到 AI Coding 工作坊課程當道，仍有機會參與到實打實的手工藝課程」— throw.in.pooooool

適合誰來上？

  • 聽過 TDD 但一直沒機會好好練習，或者試過幾次覺得卡卡的
  • 想建立正確的 TDD 開發習慣，而不是自己摸索
  • 看過 Kent Beck《Test Driven Development: By Example》(測試驅動開發：案例導向的逐步解決之道) 或 Uncle Bob《Clean Craftsmanship》(無瑕的程式碼 軟體工匠篇)，但實際上手還是沒把握
  • 想知道 TDD 怎麼跟 AI 輔助開發結合
  • 希望提升程式碼品質與開發信心
  • 想改善開發思維，在專案中真正落實 TDD

課前準備

  1. 熟悉你的開發工具 (IDE)，IDE 的熟練程度會直接影響你的練習速度，快捷鍵和測試執行方式建議課前先確認順手
  2. 如果時間允許，可以先翻閱 Kent Beck《Test Driven Development: By Example》(測試驅動開發：案例導向的逐步解決之道) 或 Uncle Bob《Clean Craftsmanship》(無瑕的程式碼 軟體工匠篇)，會讓你在課堂上更有感覺

常見問題

Q：需要先會什麼程式語言？

課程範例使用 JavaScript，但 TDD 的觀念是通用的。只要你有基本的程式開發經驗就可以參加

Q：我完全沒寫過測試，可以上嗎？

可以。課前會提供簡單的測試框架範例讓你先熟悉，課程中也會從基礎開始帶

Q：我已經會 TDD 了，還需要上嗎？

如果你照著流程走，但總覺得哪裡不太對，這堂課會幫你釐清很多細節。很多學員的回饋是「原來我之前的理解有偏差」。書上沒寫的那些思考方式和小技巧，往往就是讓你從「會做」到「做好」的關鍵

Q：課後有什麼資源？

提供示範 repo（含完整 commit 歷史），可以回頭對照每一步的變化。課後有問題也可以在相關 Discord 頻道討論

對測試和 TDD 有興趣？

之前寫過一系列跟測試相關的文章，有興趣可以看看

報名

  • 日期：2026/04/18 (六)
  • 時間：10:00 - 17:00 (中午休息一個小時，不供餐，請自行安排用餐)
  • 費用：NT 2,800- (曾上過任何一門課程的舊學員優惠價 NT 2,500-)
  • 報名連結：luma.com

注意事項

  • 本活動不開發票
  • 報名繳費後恕不退費(可轉讓名額給其他人)
  • 如果到時候無法開課，將全額(無息)退還所有費用
  • 報名後請記得一定要收信，報名後請記得一定要收信，報名後請記得一定要收信

圖片來源：AI 產生