"Integration-Test"
- Mock 邊界判斷決策表
什麼時候 mock 夠用、什麼時候需要真實服務 — 從 API 層 / 協議層 / 環境層的斷裂點判斷 mock 的適用範圍
- Protocol Integration Test
驗證程式碼和真實外部服務之間的協議互動是否正確的 test 層級
- Protocol integration test 定義
Protocol integration test 和 unit test / E2E test 的邊界 — 驗證程式碼和真實服務的協議契約，不驗證 UI 也不用 mock
- 三層定義與職責表
Unit Test / Protocol Integration Test / Screen State Test 各層職責、驗證目標與盲區的完整論述
- WebSocket 協議測試實作
對真實 ttyd 驗證 frame type 和 auth handshake — 從 T.C1 和 T.C2 的教訓推導出的 protocol integration test 設計
- 5.2 WebSocket integration test
驗證 client/server 實際互動
- 「名義 integration test」的識別與修正
test 名稱含 integration 但核心依賴全用 fake — 如何辨認、為什麼有害、怎麼修正命名和測試策略
- HTTP contract test 設計
HTTP REST API 的 protocol integration test — request/response 格式、status code 語意、error body 結構的驗證
- Nominal Integration Test（名義整合測試）
名稱含 integration 但核心依賴全用 fake 的 test，驗證內部狀態機而非真實服務互動
- CI 中的服務 fixture 管理
在 CI 中啟動和停止真實服務的 test harness 設計 — Process.start / Docker / testcontainers 三種方案的適用場景
- T.C5 凍結參照失效被 stub 遮蔽 — 測試全綠、功能全壞
前端把後端資料的 id 凍結在本地記錄裡，後端的合併操作會重建資料、舊 id 全部失效 — 單元測試的 stub 由測試自己餵資料，永遠不會經歷「id 死亡」，bug 存在期間所有測試綠燈
- 成本判斷表
什麼時候值得寫 protocol integration test、什麼時候用 contract test 或實機測試替代 — 根據服務啟動成本和協議複雜度判斷
- 真實後端驗證測試
服務無法本機啟動、只有共用測試環境（staging）時，把對真實後端的行為驗證寫成常駐測試：離線降級為跳過、憑證失效必須紅燈，讓假後端固化的行為假設有地方對真實後端驗證
- 語意級假後端與流程測試
bug 的成因是對後端行為的假設錯誤、由測試餵資料的 stub 驗證不出來時：建一個持有狀態、模擬已證實後端行為的假後端（test double 分類的 fake），讓流程測試走完整的多服務互動鏈
- Real-Backend Verification Test（真實後端驗證測試）
對共用測試環境常駐斷言後端業務行為的測試；紅、綠、跳過各有語意，承接假後端固化行為的漂移警報
- 測試憑證管理
測試環境的帳號密碼放在哪裡、CI 怎麼拿到、怎麼防止對生產環境執行 — 存放策略的適用前提與失效偵測
- TestWidgetsFlutterBinding 會擋掉真實網路：真實後端測試與流程測試的檔案級隔離
flutter_test 的 binding 初始化後會把 HttpClient 換成回 400 的假件——需要真實網路的後端驗證測試不可初始化 binding，也因此不可 import 任何會初始化 binding 的 harness。靠測試檔案各自跑在獨立 isolate 的特性，兩種測試在同一個目錄共存。
- 192 個測試全過、實機全壞：Mock 遮蔽真實行為的三層測試策略
unit test 全綠、實機部署後功能整片壞掉。mock-only 策略的結構盲區（text vs binary frame、缺 auth handshake、ANSI 多樣性被 FakeWebSocketChannel 遮蔽），以及分層測試各抓什麼、各遮蔽什麼。