DevOps Taiwan Meetup #75（實體）- TDD 隨你問 之 AMA 你今嘛底刁位 活動筆記
14 Jan 2026Post Directory
event: https://devops.kktix.cc/events/meetup-75
前言
好久沒參加實體的技術 Meetup 了！從 TDD (Test-Driven Development) 入門到放棄的我在之前公司導入時遇到蠻多問題的，這次活動很特別是 AMA (Ask Me Anything) 的形式，就來看看大家都遇到了些什麼問題，以及講師如何化解
TDD 這東西大家都聽過，但真的要在專案裡落地，通常都會遇到「老闆不給時間」、「同事不想寫」、「寫了測試反而更難改」等等的鬼故事。所以這篇筆記多為台下會眾提出問題，以及講師的回覆整理而成的。
為什麼選 SLOT 當 TDD 範例？
活動一開始有個有趣的問題，為什麼講者喜歡用 SLOT (拉霸機) 當作 TDD 的範例？
這其實牽涉到測試最討厭的兩個東西：時間與亂數。
寫過測試的都知道，如果程式碼裡面有 Random() 或是 Date.now()，每次跑出來結果都不一樣，測試要怎麼寫？ (ﾟ∀。)
而 SLOT 剛好就是需要「真正的亂數」（不然在賭場會被告死），同時又要能被驗證。如果連這種極端情境都能透過 TDD 馴服，那一般商業邏輯的情境應該都沒問題了。
AI 時代的 TDD：該怎麼配合？
現在寫 Code 不用 Copilot 好像就不會寫了一樣（誤）。大家最好奇的就是：AI 自動產生的程式碼常常不受控，TDD 該怎麼結合 AI？
講者提到一個觀點：AI 本身就是個黑盒子，試圖去「控制」它不要走歪，其實有點本末倒置。
如果是用 AI 直接產出一大坨程式碼，當然很容易發生 AI 幻覺或是邏輯越走越偏。這時候 TDD 的精神就來了——縮小步幅 (Baby Steps)。
不要叫 AI 一次寫完整個功能，而是一步一步、一個小測項一個小實作的推進。當 Context（上下文）透過這些小步驟慢慢建立起來，AI 就會越來越懂你的邏輯，產出的品質也會跟著提升。簡單說，還是要回歸 TDD 的初衷，積沙成塔嘛。
團隊導入：如何讓同事不痛苦？
這應該是所有 Tech Lead 的痛。一開始大家去 Dojo 練功都很熱血，回到專案過兩週就沒人寫了 Σ(ﾟДﾟ；≡；ﾟдﾟ)。
講者給出了一句金句：
「人教人不會，事情教人才會。」
常常有人問怎麼導入，但其實硬推是沒用的。講者分享了自己的經驗：一開始自己默默寫，過了半年，資深的 QA 開始發現「欸？接你的單子好像比較輕鬆，回測都綠燈」，這種正向的體驗自然會擴散出去。
如果不夠痛，同事就不會想改變。什麼時候最痛？改那些沒文件又沒測試的 Legacy Code 的時候。 這時候不要一開始就要求覆蓋率 100%，而是針對「修改舊的關鍵功能」開始補單元測試。從解決痛苦的角度切入，大家才會有感。
Mock 地獄與重構的勇氣
寫測試寫到後來，最怕的就是 Mock 滿天飛。只要稍微改個內部實作，測試就壞光光，變成「測試在卡重構」，而不是「測試在輔助重構」。
這通常代表測試過度關注了實作細節，而不只是行為本身。
這邊講者釐清了一個觀念循環： 需求 (Requirements) <- 幫助重構 (Refactoring) <- 保證正確性 (Correctness)
TDD 的核心價值之一是幫助重構（解決非功能需求）。如果單元測試變成了重構的阻礙，那往往代表我們 對內部互動做了過多假設，用 Mock 把實作細節綁得太死。
這時候該怎麼辦？ 答案有點反直覺：試著相信你的程式碼。如果某些 Mock 已經開始妨礙重構，可以考慮暫時拔掉它。只要你的整合測試（或更高層級的測試）仍然能保護對外行為，那這些單元測試本身就值得被重新檢視。
重點是：測試是用來保護程式的，但當程式的行為足夠穩定時，它也能反過來保護測試，讓重構變得更有餘裕。
God Object (上帝物件) 怎麼辦？
大家專案裡一定都有那種 User 或是 Order 物件，包山包海什麼功能都有
而在各種地方的整合測試中，可能會誕生出各類的 Mock，例如 MockCaseAUser, MockCaseBUser，這種 Anti-pattern
可能是專案迭代過程中不段添加上去的，大家都知道不好，但就是不敢動。
問這個問題的人，其實心裡都知道答案了。講者笑說，這時候缺的不是技術，而是一點點踏出第一小步的勇氣。這聽起來很雞湯，但面對巨大的技術債，除了捲起袖子先拆一行是一行之外，好像也沒別的捷徑了 (つд⊂)。
測試的 ROI：考績該怎麼算？
用「鼓勵」寫測試的方式降低團隊成員寫測試的習慣，如果納入 KPI 又怕大家為了刷覆蓋率寫出一堆垃圾測試，該怎麼權衡？
講者建議從 商業價值 來看：
- 找公司絕對不能錯的地方：例如虛擬貨幣交易所，金流算錯絕對比通知信沒寄到還嚴重 N 倍。
- 優先級：從老闆和用戶的角度看，錢不見了會被告，信沒收到頂多被客訴。
所以測試也要講求 CP 值（ROI）。測試的粒度盡量越大越好（靠近使用者行為），這樣在重構內部黑箱邏輯時，測試才不會一直壞掉，這才是高 CP 值的測試。
結語
這次 Meetup 聽下來，感覺 TDD 不僅僅是一種寫 Code 的順序（紅燈->綠燈的過程），更是一種設計思維。
很多時候我們覺得 TDD 難推，是因為我們習慣先想 Solution (Implementation)，但 TDD 強迫我們從 Program (Usage/Interface) 的角度去思考。這跟我們理工科系一路以來的訓練是相反的。
不過就像講者說的，不用急著一次到位，先從讓自己不痛苦開始吧！
