❯❯ 規格不漂移，測試不改鬆：當 E2E 測試成為系統的 Single Source of Truth

📍 流水線位置｜入口 → flow → 型別 → mock → 【測試】 → UI → vibe → 上線

在傳統開發思維中，自動化測試常被視為後置的品質防線，多數專案的測試都是事後才補：功能寫完、行有餘力再補幾條，求個心安。這種測試的身分就像保險，出事時希望它能發揮理賠作用。

但在自動化流水線架構中，E2E 測試本身就是系統的主規格（SSOT）。系統的「預期行為與範疇」不再只是靜態文件，而是落實為 test/e2e/specs/ 目錄下的 20 個測試檔案與 150 條測試案例。這 150 條並非手動逐條撰寫，而是透過 Day 04 測試鏈指令（/test e2e spec）依據 Flow 文件的商業不變量（ Business Invariants）自動生成，並直接納入凍結範圍。

兩者的差別在哪？靜態文件會隨時間逐漸失真，且往往過期得無聲無息；但測試套件在 CI/CD 管道中擁有強制執行力。一旦系統實作偏離預期行為，紅燈會立即中斷流程。合約不會無聲漂移，因為它每次都會被執行。

E2E 驗的不是元件，是承諾

相較於單元測試專注於模組內部的邏輯，E2E 測試站在真實使用者的操作視角：發起頁面導覽、觸發介面互動，並驗證最終的渲染結果。

它斷言的對象是 Flow 文件裡定義的商業不變量（Business Invariants），包含賓客資料的識別邏輯、狀態轉換的語意，以及跨頁面流程的完整性。它不干涉元件內部的封裝細節，只聚焦於驗證系統對外承諾的業務邏輯是否確實兌現。

唯有使用領域模型的語言來撰寫語意結構，測試才能真正承載「系統介面合約」的重量。

規格凍結政策（Freeze Policy）

主規格建立後，還需要一套治理機制來守護——規格凍結。在目錄結構上，我們劃出了清晰的邊界：

test/e2e/
├── specs/    ← 主 spec：業務合約。凍結（20 檔 150 條）
├── vibe/     ← vibe 測試：行為紀錄。不凍結（38 檔 130 條，Day 21 詳談）
└── helpers/

專案規範裡白紙黑字寫明：不得修改 test/e2e/specs/（主 spec 凍結，SSOT 政策）。同時，這項規範也連帶鎖住了上游的 spec/gherkin-feature/ 與 spec/e2e-flows/。邏輯很簡單：如果上游規格能隨手放行，主測試套件的凍結政策便形同虛設，失去架構防護的意義。

補充說明，Day 01 提及的全系統 280 條測試，即由主 spec 的 150 條與 vibe 區的 130 條組成。前者是受凍結政策保護的核心合約，後者則是隨系統演進動態擴充的測試。

為什麼要立下「不得修改」這麼強硬的鐵律？因為在趕交付的壓力下，把斷言調鬆永遠是最省事、最快速的捷徑。測試紅了、時程緊了，「先改測試讓它過」看起來無傷大雅，但這種破例一旦被允許，測試套件就會迅速失去驗證效力，最終退化成一排永遠綠燈的裝飾品。

凍結政策正是為了杜絕這種妥協。當測試紅燈時，唯一的合法修復路徑就是修產品程式碼，讓實作重新貼合合約規範。

凍結治理與合約修訂機制

這個約束設有明確的例外路徑，並非一凍結就毫無彈性：

1. 分層管理機制：
   凍結範圍僅限 specs/ 核心業務合約層，後續 Vibe 階段建立的測試不在此限。不過，非凍結區的測試異動仍不允許自動化工具自己決定，規範要求工具在測試失敗時列出修復選項交由人工決策，絕不能擅自刪改。

2. 正式合約變更流程：
   當業務邏輯確實調整時，合約允許修訂，但必須走完完整流程。以 Day 08 拆分賓客回收區為例：需先確認決策、建立 Issue 追蹤、同步更新 Flow 文件與測試套件，並在 API 層留下備忘。凍結攔截的是私下隨意修改，而非經過審核的正當業務調整。

「測試即合約」正是依賴這三大支柱支撐：

• 用領域語言定義
• 每天自動化執行
• 異動有嚴格約束。

話說回來，即便 150 條主規格測試全數 pass，依然無法完全排除隱藏的架構風險。

下一篇來拆三個真實發生的異常個案：測試全綠卻在正式環境出問題的、內部稽核挖出來的未爆彈，以及環境因素造成的測試誤報。綠燈的守備範圍到底有多大，明天見真章！

🎒 最小一步｜ 挑出你專案最核心的三支 E2E 測試，跟團隊約好這三支的斷言不許改：紅燈時只能靠修產品程式碼變綠。
📎 本篇證據｜ test/e2e/specs/（20 檔 150 tests）・.claude/CLAUDE.md「不得修改 test/e2e/specs/（主 spec 凍結，SSOT 政策）」原文