iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Software Development

AI 時代的 TDD:讓 AI 寫 Code,但不要讓它決定品質 系列

AI 可以加速 Red-Green-Refactor 循環的每一步,但「這個測試值不值得留、覆蓋夠不夠、重構要不要做」這些品質判斷,不能交給 AI 自己決定。這個系列會用真實踩坑案例,拆解 AI 寫測試時最容易忽略的品質陷阱,以及怎麼建立紀律讓 TDD 循環真的落實。

參賽天數 22 天 | 共 22 篇文章 | 1 人訂閱 訂閱系列文 RSS系列文
DAY 11

Day 11:讓 AI 遵守「先紅後綠再重構」的流程設計

前言 「我知道 TDD 的三個步驟,但要怎麼讓 AI 真的照著做,而不是嘴巴上說『好的,我會遵循 TDD』,實際上還是一次把東西全寫完?」 這是這幾天讀者留言裡...

2026-09-19 ‧ 由 recca0120 分享
DAY 12

Day 12:測試命名——AI 寫的測試名稱看起來詳細,實際傳達了什麼?

前言:名稱長不等於資訊多 「這個測試名稱都寫了 test_calculate_discount_with_member_level_and_coupon_ret...

2026-09-20 ‧ 由 recca0120 分享
DAY 13

Day 13:Mock 的濫用——AI 傾向 mock 一切,隔離過頭反而測不到整合行為

前言:「單元測試要隔離依賴」,這句話本身沒有錯 「單元測試要隔離外部依賴」是每個測試教學都會強調的第一課,AI 也把這句話學得很熟——熟到一個危險的程度:只要看...

2026-09-21 ‧ 由 recca0120 分享
DAY 14

Day 14:案例——一個被過度 mock 掉的測試,通過了但沒抓到真正的 bug

前言:測試綠燈、CI 綠燈,為什麼上線還是炸了? 「這支測試把外部依賴都 mock 掉了,應該很單純、很穩定吧?」 昨天談到 AI 傾向把待測物件依賴的每一個東...

2026-09-22 ‧ 由 recca0120 分享
DAY 15

Day 15:邊界情境——AI 容易只測 happy path,例外情境要人主動要求

前言:測試都寫了,為什麼上線後還是被邊界案例絆倒? 「我讓 AI 幫這個函式補了測試,涵蓋率也不低,怎麼上線後第一週就被一個空陣列輸入搞掛了?」 這是我接手一套...

2026-09-23 ‧ 由 recca0120 分享
DAY 16

Day 16:測試品質的判斷標準——AI 可以幫你寫,但誰來判斷這個測試值不值得留?

前言:測試都在,為什麼還要問「值不值得留」? 「這個檔案裡已經有 40 個測試案例了,還要花時間逐條審查嗎?」 如果你也這樣想過,先想一件事:這 40 個測試案...

2026-09-24 ‧ 由 recca0120 分享
DAY 17

Day 17:Coverage 不是品質——AI 很容易把「覆蓋率高」當成「品質好」的證據

前言:覆蓋率 95%,為什麼還是不敢重構? 「這個模組的測試覆蓋率有 95%,理論上應該很安全,為什麼團隊還是不敢動它?」 上一篇(Day 16)談到「誰來判斷...

2026-09-25 ‧ 由 recca0120 分享
DAY 18

Day 18:案例——100% 覆蓋率,但測試對重構完全沒有防護力

前言:覆蓋率報告顯示 100%,這不是應該最安心的狀態嗎? 「這個模組的覆蓋率報告顯示 100%,代表每一行、每一個分支都被測試跑過,重構起來應該很放心吧?」...

2026-09-26 ‧ 由 recca0120 分享
DAY 19

Day 19:讓 AI 寫 Test Double 時要注意的邊界——Dummy/Stub/Fake/Spy/Mock

前言:反正都是「假的依賴」,選哪一種有差嗎? 「Test Double 不就是拿一個假的物件頂替真的依賴嗎?隨便用一種 mocking 框架生一個出來,測試能跑...

2026-09-27 ‧ 由 recca0120 分享
DAY 20

Day 20:TDD 循環被打斷的真實情境——AI 一次生成了完整實作 + 完整測試

前言:一次到位,聽起來像效率,其實是循環被打斷 「請幫我實作這個功能,記得寫測試。」這句話丟給 AI,十之八九會得到一份「實作 + 測試」同時完工的回應——兩個...

2026-09-28 ‧ 由 recca0120 分享