現代軟體測試與 AI 實戰 (1)：自動化測試入門與 TDD 核心思維

為什麼我們需要自動化測試？

在軟體開發的日常中，你是否常遇到以下場景：

• 「這個 Bug 我不是上個月才修過嗎？怎麼又出現了！」
• 「加了一個新功能，結果把購物車結帳的舊功能給弄壞了...」
• 「這段程式碼好可怕，完全不敢動它，動了怕系統整組壞掉 (Legacy Code)。」

這就是為什麼我們需要 自動化測試 (Automated Testing)。它就像是一道安全網，確保你的每一次改動（無論是加新功能或重構）都不會破壞既有的商業邏輯。

測試的顆粒度有很多種，但最基礎、也是開發者最需要掌握的，就是 單元測試 (Unit Test) 與 整合測試 (Integration Test)。

單元測試 (Unit Test)

單元測試是最小顆粒度的測試，通常用來驗證一個 Function 或一個 Class 的邏輯是否正確。

• 特點：執行極快（幾毫秒內完成）、外部依賴（如 Database、API）通常會被 Mock（假物件）無情替換掉。
• 目的：確認你在 if/else 控制流程中的商業邏輯算不算得對。

整合測試 (Integration Test)

當多個「單元」組合在一起時，還能正確運作嗎？這就是整合測試的工作。

• 特點：會跨越多層系統（例如前端打 API，API 寫入真的 Test DB），執行速度較慢。
• 目的：確保系統元件之間的「連接點」與「資料拋轉」沒有問題。

TDD（測試驅動開發）的核心精神

說到測試，就不能不提 TDD (Test-Driven Development)。這不僅僅是一種寫測試的方法，更是一門「設計軟體架構」的哲學。

傳統開發習慣是：先寫 Code ➔ 靠感覺手動測試 ➔ 沒問題就上線 ➔ 常常出包。

而 TDD 提倡的思維是：先寫測試 ➔ 讓測試失敗 ➔ 寫最少量的 Code 讓測試通過 ➔ 安全地重構。

TDD 的三大循環：紅燈、綠燈、重構

1. 🔴 紅燈 (Red)：在寫任何產品代碼前，先寫出一個「預期它會失敗」的測試。這逼迫你先從「使用者 (呼叫端)」的角度去思考 API 或 Function 的介面該長什麼樣子。
2. 🟢 綠燈 (Green)：寫下「最少、甚至最醜」的產品代碼，只要能讓剛剛那個測試通過（變綠燈）就好。目標是快速驗證邏輯可行性。
3. 🔵 重構 (Refactor)：在「綠燈已經保護你」的安全網下，放心大膽地整理這段代碼。消除重複、調整變數名稱、套用設計模式，因為只要測試還亮綠燈，你就知道你沒把系統弄壞。

TDD 看似美好，但痛點在哪？

雖然 TDD 架構能帶來極高的代碼品質與信心，但為何現實中推行往往困難重重？

1. 初期速度慢：老闆要功能，但工程師卻還在寫測試。
2. 規格變動快：需求朝令夕改，寫好的測項每天都在廢棄。
3. 設定整合環境痛苦：要寫出一個有連 DB 的測試，光是搞 Docker 跟假資料就花掉半天。

這也是為什麼在後續的文章中，我們將探討常見的測試反模式（例如冰淇淋筒），以及在這波 AI 浪潮（GenAI & LLM） 下，我們該如何運用 AI Agent 大幅降低撰寫測試的心智負擔，甚至把寫規格、抽測項、寫代碼、驗收測試，整合成自動化閉環！

下一篇，我們將進入觀念分支，探討現實開發中最令團隊頭痛的架構怪獸：測試金字塔的崩塌：冰淇淋筒反模式。