iT邦幫忙

tdd相關文章
共有 207 則文章
鐵人賽 Software Development DAY 26

技術 Day 26:個人心得——從「相信人眼 review」到「相信可執行規則」的轉折

前言:我曾經也覺得「多寫一點防禦性程式碼比較安全」 這篇不打算再講案例數字,想單純誠實地講一段自己的心路歷程。因為如果不誠實面對自己曾經站在哪一邊,這整個系列講...

鐵人賽 Software Development DAY 30

技術 Day 30:總結——如果重來一次,AI 時代的 TDD 該怎麼練

前言:為什麼要寫這個系列 決定寫這個系列之前,我心裡其實有點猶豫。市面上不缺「AI 幫你寫測試」的教學文,大多停在「叫 AI 生成一段測試程式碼」這個層次——這...

鐵人賽 Software Development DAY 29

技術 Day 29:這套方法論的邊界——TDD 解決不了什麼問題

前言:講了 28 天「怎麼做對」,今天要誠實講「做不到什麼」 這個系列從 Day 01 講到現在,一直在談怎麼讓 AI 遵守 Red-Green-Refacto...

鐵人賽 Software Development DAY 28

技術 Day 28:AI 時代 TDD 的分工模型——AI 產生候選方案,人做品質判斷

前言:把 27 天的技巧收攏成一張分工圖 昨天列出三個不能外包的判斷(留不留、夠不夠、做不做),今天要把這件事講得更完整:不是零散地在幾個時間點介入,而是有一個...

鐵人賽 Software Development DAY 27

技術 Day 27:品質把關不能外包給 AI 的三個判斷——留不留、夠不夠、做不做

前言:技術上都對,但不代表可以放手 「AI 寫的測試邏輯沒錯、覆蓋率也達標、重構建議也合理,這樣還不能放心交給它嗎?」 這個系列走到第 27 天,講過很多 AI...

鐵人賽 Software Development DAY 26

技術 Day 26:遺留系統補測試——AI 適合先寫特徵測試(characterization test)嗎?

前言:昨天才說不要為了通過而改鬆斷言,今天卻要談「不管對不對先釘住」? 「昨天才講不能為了讓測試變綠就放寬斷言,今天卻要教 AI 寫一種『不管現在的行為對不對,...

鐵人賽 IT Operation DAY 30

技術 Day 30:品質防線要自己蓋——這個系列 30 天的回顧

前言:為什麼寫這個系列 我自己維護 omnipay-ecpay 這個公開套件已經好幾年,一直有個念頭:這套件的品質防線到底可不可靠,我其實從來沒有認真盤點過。C...

鐵人賽 Software Development DAY 25

技術 Day 25:案例——AI 把測試改鬆來讓 CI 通過,而不是修好程式碼

前言:紅燈亮了,AI 的第一反應是什麼? 「CI 紅了,AI 說已經修好了,一看 diff 才發現它改的是測試檔案,不是程式碼。」 這句話乍聽有點荒謬——修 b...

鐵人賽 Software Development DAY 24

技術 Day 24:案例——一次 AI 寫測試掩蓋掉真正 bug 的真實除錯過程

前言:進入第四部,用真實案例把前面 23 天的原則串起來 從今天開始是這個系列的第四部:實戰案例與總結。前面 23 天講了不少原則——假陽性測試、過度 mock...

鐵人賽 Software Development DAY 23

技術 Day 23:AI 協作下的 Pair Programming——人 navigator,AI driver 的分工模式

前言:這一部(Day8-16 到 Day17-23)都在講怎麼「管住」AI,今天談怎麼「跟」AI 一起工作 前面幾天講了很多「防止 AI 犯錯」的具體技巧——分...

鐵人賽 Software Development DAY 22

技術 Day 22:案例——把一個大任務拆成多輪 TDD 循環後,品質有什麼不同

前言:「反正最後都要交出同一份程式碼,拆不拆有差嗎?」 「一個訂單折扣計算功能,規則不算複雜——會員等級折扣、優惠券、滿額贈品,一次講清楚讓 AI 寫完,跟拆成...

鐵人賽 Software Development DAY 21

技術 Day 21:怎麼強迫 AI 拆解成小步驟,逐步紅綠重構

前言:三階段流程都照做了,為什麼還是感覺在趕工? 「我已經照 Day 11 教的方式,把任務拆成『寫測試展示失敗 → 補實作展示通過 → 重構』三個階段,每個階...

鐵人賽 IT Operation DAY 25

技術 Day 25:幫 Refund 補一個例外測試,只花了 13 行

前言:不等新功能當藉口,主動補一個例外測試 第二部看過 commit 80d3469「順路補測試」的真實案例——加新功能時,順便把舊路徑的測試缺口補上。今天反過...

鐵人賽 Software Development DAY 20

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

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

鐵人賽 Software Development DAY 19

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

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

鐵人賽 Software Development DAY 18

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

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

鐵人賽 Software Development DAY 17

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

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

鐵人賽 Software Development DAY 16

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

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

鐵人賽 Software Development DAY 15

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

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

鐵人賽 Software Development DAY 14

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

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

鐵人賽 Software Development DAY 13

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

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

鐵人賽 Software Development DAY 12

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

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

鐵人賽 Software Development DAY 11

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

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

鐵人賽 Software Development DAY 10

技術 Day 10:Refactor 階段——AI 最容易跳過的一步,沒有安全網的「順手重構」

前言 「反正測試都綠燈了,AI 順手把旁邊那個函式也改乾淨一點,應該沒差吧?」 這句話聽起來像是效率的展現——都已經打開這個檔案了,看到旁邊有一段程式碼寫得不太...

鐵人賽 IT Operation DAY 14

技術 Day 14:制度 vs 自覺,哪個更靠得住

前言:制度跟自覺,哪個更靠得住? 第二部用一筆真實的 commit,帶出了一連串觀察。今天把它們收在一起,回答一開始留下的問題:制度跟自覺,哪個更靠得住? 今日...

鐵人賽 Software Development DAY 9

技術 Day 09:案例——AI 為了讓測試綠燈,硬編碼了預期值

前言:測試綠了,是因為邏輯對了,還是因為它「記住了答案」? 「昨天講到 AI 在 Green 階段容易寫出『讓測試通過的最小手段』,聽起來有點抽象——最小手段到...

鐵人賽 Software Development DAY 12

技術 【Day - 12】規劃過期、Bug、平行開工,Spectra 怎麼協助 apply?

前兩篇看過 Spectra 的基本流程,以及指引、文件檢查與歸檔的安排。這篇接著看 apply 前後:規劃文件準備好了,AI 開始實作時,還會遇到哪些問題? 例...

鐵人賽 Software Development DAY 8

技術 Day 08:Green 階段——AI 傾向寫出「讓測試通過的最小手段」

前言:「用最少的程式碼讓測試通過」,這句話不是每個人聽起來都一樣 「Kent Beck 自己都說了,Green 階段就是要用最簡單的方式讓測試通過,AI 這樣做...

鐵人賽 Software Development DAY 7

技術 Day 07:為什麼「先看紅燈」比「有沒有寫測試」更重要

前言:檢查有沒有寫測試,是最容易被騙過的一種檢查 「這個 PR 有沒有寫測試?」這句話幾乎是每個團隊 code review 時的標準問句。它很好回答——打開檔...

鐵人賽 Software Development DAY 6

技術 Day 06:Red 階段——AI 容易跳過「先看到測試失敗」這一步

前言:測試從沒紅過,你怎麼知道它會抓到問題? 「反正最後測試都是綠的,中間有沒有真的紅過一次,有差嗎?」 有差,而且差別很大。昨天講完假陽性測試的三種樣貌——空...