"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 結構的驗證
- 名義 Integration Test
名稱含 integration 但核心依賴全用 fake 的 test，驗證內部狀態機而非真實服務互動
- CI 中的服務 fixture 管理
在 CI 中啟動和停止真實服務的 test harness 設計 — Process.start / Docker / testcontainers 三種方案的適用場景
- 成本判斷表
什麼時候值得寫 protocol integration test、什麼時候用 contract test 或實機測試替代 — 根據服務啟動成本和協議複雜度判斷
- 192 個測試全過、實機全壞：Mock 遮蔽真實行為的三層測試策略
unit test 全綠、實機部署後功能整片壞掉。mock-only 策略的結構盲區（text vs binary frame、缺 auth handshake、ANSI 多樣性被 FakeWebSocketChannel 遮蔽），以及分層測試各抓什麼、各遮蔽什麼。