跳轉到

5.3 整合測試與端到端測試#

為什麼需要上層測試#

單元測試（5.2 節）驗證的是「單一函式/類別」的正確性。但單元各自正確，不保證整個系統正確——問題往往出在「單元之間如何協作」。整合測試與端到端測試，正是往上補足單元測試看不到的盲區。

一個經典的比喻：單元測試檢查「每個零件都沒壞」，整合測試檢查「零件組裝後能不能動」，端到端測試檢查「整台機器用戶能不能順利用」。

整合測試：驗證模組之間的協作#

整合測試（Integration Test） 驗證多個模組/元件整合在一起是否能正確互動、傳遞資料、協同工作。

常見的整合衝突（單元測不到、整合才抓得到）： - 介面契約不符：A 模組回傳的格式 B 模組解析錯誤 - 資料型別/格式微差：時間格式、時區、編碼不一致 - 狀態流傳錯誤：前一個模組設的狀態，下一個模組讀錯 - 資料庫 Schema 與程式碼不符 - 外部服務呼叫錯誤：API 路徑、參數、權限

# 整合測試：服務層 + 真實資料庫（非 mock）
def test_checkout_persists_order(db):
    order_id = checkout_service.execute(valid_cart, db)
    saved = db.orders.fetch(order_id)
    assert saved.status == "CONFIRMED"
    assert saved.total == 90.0

整合測試的策略重點： - 驗證「真實的互動」——通常用真的資料庫、真的外部服務（或輕量假服務），而不是全 mock - 比單元測試慢、比 E2E 快，是「金字塔」的中堅 - 重點放在模組互動的邊界，而非重複測試單元內部邏輯

端到端測試：模擬真實使用者流程#

端到端測試（E2E, End-to-End） 從使用者角度驅動整個系統，走完一條完整的業務流程，驗證從介面到後端到資料庫都正確合作。

典型的 E2E（以 Playwright 為例，驅動瀏覽器）：

test('使用者完整結帳流程', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#username', 'user123');
  await page.click('button:has-text("登入")');

  await page.goto('/cart');
  await page.click('text=進入結帳');
  await page.fill('#coupon', 'SAVE20');
  await page.click('button:has-text("確認付款")');

  await expect(page.locator('text=訂單成立')).toBeVisible();
});

E2E 的定位： - 最接近真實、最有信心的測試 - 但最慢、最脆弱、最難維護（依賴整個環境、時間、螢幕、外部服務） - 因此數量要少、只測高價值完整流程（金字塔頂端）

測試環境的重要性#

測試不是只在「你的筆電上」跑。不同測試層次需要不同的環境：

  • 單元測試：快、隔離，幾乎任何環境都能跑
  • 整合測試：需要真的資料庫/服務 → 測試環境（Test Environment）
  • E2E 測試：需要完整部署的系統 → 預發布/暫存環境（Staging）

現代做法是讓測試在 CI（持續整合）中自動化執行（6.1 節），並用「測試環境」「預發布環境」在合併前、發布前自動跑測試。這把「測試」從「人記得跑」變成「系統強制跑」，是品質護欄的關鍵（4.5、12.4 節）。

測試的信任層次：測試越多越安心，但不盲目#

整合測試與 E2E 給了我們「越多測試越有信心」的錯覺，但有三點要小心：

  1. 信任要有「成本意識」：E2E 昂貴而脆弱，不是「越多越好」，而是「精選高價值流程」
  2. 測試也有「腐化」：測試寫得亂、依賴實作細節、flaky（時好時壞），會讓團隊失去對測試的信任，進而忽略紅燈
  3. 測試覆蓋不了「沒定義的事」：測試只證明「定義過的行為對」，無法發現「你根本沒想過的需求」——這是需求工程（第 2 章）的領域

成熟團隊的信任是階梯式的：單元測試保證底層邏輯、整合測試保證協作、E2E 保證關鍵流程，再加上人工的探索/驗收——各層互補，形成完整的品質網。

AI 時代的整合與端到端測試#

AI 時代，這三層測試的意義更形重要：

  • AI 生成或修改程式碼後，需要整合/E2E 測試來確認「沒有破壞模組間的既有協作」——這正是「迴歸測試」（5.6 節）的核心，也是 AI 自主迴圈的重要驗證（4.4 節）
  • AI 可以協助撰寫整合測試（設定資料、模擬真實互動）與 E2E 測試（產生使用者流程），大幅降低上層測試成本
  • 但 AI 產生的 E2E 更容易「假裝測過」：例如斷言寫得太鬆、或測試依賴 UI 文字而脆弱。審查 AI 產生的上層測試，比審查其產生的單元測試更不能馬虎

一句話：整合與 E2E 是「確認整個系統（含 AI 產生的部分）仍能正確協作」的關鍵驗證——在 AI 大量注入程式碼的時代，這正是最需要的安全網。

本章小結#

  • 單元正確 ≠ 系統正確；整合與 E2E 補足協作盲區
  • 整合測試：驗證模組間互動，用真實依賴（金字塔中層）
  • E2E 測試：從使用者角度跑完整流程，最真實也最貴最脆（金字塔頂端）
  • 用測試/預發布環境在 CI 中自動化執行
  • 信任是階梯式的：各層互補；測試也有「腐化」風險
  • AI 時代：這些上層測試是確認「AI 注入後系統仍能協作」的關鍵安全網

想一想#

  1. 舉一個「單元測試全綠、但整合起來出錯」的真實案例，說明問題出在「協作」。
  2. 為什麼 E2E 測試「不是越多越好」？它貴和脆在哪裡？
  3. 讓 AI 為你的專案寫一個整合或 E2E 測試，檢查它是否「斷言得太鬆、只證明有跑過」。