Integration Test 整合測試

測試多個模組或服務串起來後是否正常。

先用一句話理解

測試多個模組或服務串起來後是否正常。

打個比方

像測廚房、櫃台、收銀是否能一起完成一筆訂單。

什麼時候會遇到

API 串資料庫、登入流程、付款流程、第三方服務整合時。

再往深一點看

Integration test 跨越了單一函式的邊界，測試的是「多個模組在一起運作時是否正確」——例如你的 API route 接收請求後，是否真的把資料寫進資料庫、再正確回傳結果。和 unit test 不同，integration test 通常不 mock 掉所有依賴，而是讓真實的程式碼路徑跑起來，可能真的連一個測試用的資料庫（如 Supabase 的測試專案）或使用真實的 Stripe sandbox。和 e2e test 不同，integration test 不從瀏覽器模擬使用者操作，而是直接在程式碼層呼叫函式或打 HTTP 請求，所以比 e2e 快很多、也比較容易定位問題出在哪個模組。Integration test 最適合測 API 層：「這個 POST /api/orders endpoint 收到正確參數後，是否在 orders 資料表建立一筆紀錄並回傳 201」。

舉個例子

你用 Vitest 寫一個 integration test，直接呼叫 createOrder() 服務函式，並連線到 Supabase 的測試資料庫。測試斷言：呼叫後資料庫確實多了一筆訂單、函式回傳正確的 orderId、庫存也對應扣減了——這三件事一起跑，才能確認 API 邏輯和資料庫串接都是對的。

常見誤解

- 只靠 unit test 確認每個函式沒問題，卻從沒跑 integration test，結果上線後才發現 API 和資料庫的欄位名稱對不上——每個零件都對，但組起來就壞。
- Integration test 連到正式資料庫跑，測試新增的假資料污染了真實資料、或刪到真實紀錄，應該另開測試專用的資料庫或用 transaction rollback 清除測試資料。
- Integration test 和 unit test 沒有分開管理，全塞在同一個測試指令裡跑，導致需要連線才能跑的整合測試讓整個測試套件變慢，開發途中不再想常跑。