現代軟體測試與 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）。TDD 是一種寫測試的方法，也是一門「設計軟體架構」的哲學。

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

TDD 提倡的思維則是先寫測試，讓測試失敗，再寫最少量的 Code 讓測試通過，最後安全地重構。

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

TDD 的一輪循環是紅燈、綠燈、重構：先寫一個會失敗的測試，再寫剛好讓它通過的最少量程式碼，最後在測試保護下整理程式碼。

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

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

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

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

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

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