"Testing"
- Mock 邊界判斷決策表
什麼時候 mock 夠用、什麼時候需要真實服務 — 從 API 層 / 協議層 / 環境層的斷裂點判斷 mock 的適用範圍
- Protocol Integration Test
驗證程式碼和真實外部服務之間的協議互動是否正確的 test 層級
- Protocol integration test 定義
Protocol integration test 和 unit test / E2E test 的邊界 — 驗證程式碼和真實服務的協議契約，不驗證 UI 也不用 mock
- T.C1 WebSocket text/binary frame 被 FakeWebSocketChannel 遮蔽
Flutter app 用 Uint8List 發送 WS 資料走 binary frame，ttyd 期望 text frame 靜默忽略 — FakeWebSocketChannel 的 sink.add 接受 dynamic 不區分 frame type，192 個 test 全過但實機無回應
- Widget test 的狀態覆蓋策略
從畫面狀態矩陣推導 widget test case — 每個狀態的顯示、操作、退出路徑都是獨立的斷言目標
- 三層 log 設計
連線生命週期 log、protocol 訊息 log、使用者行為 log — 三層各自的職責、詳細程度和啟停控制
- 三層定義與職責表
Unit Test / Protocol Integration Test / Screen State Test 各層職責、驗證目標與盲區的完整論述
- 5.1 時間注入與狀態轉移測試
讓時間相關邏輯可重現
- 7.1 把 handler 邏輯拆成可測單元
分離 HTTP 協定處理與核心邏輯
- Mock 遮蔽
mock 模擬 API 層但不模擬協議層，造成的結構性驗證盲區
- Mock 遮蔽機制分析
Mock 在 API 層、協議層、環境層之間製造的結構性盲區 — 斷裂點在哪、為什麼 mock 無法也不應該模擬協議行為
- T.C2 Auth handshake 邏輯缺失被 FakeWebSocketChannel 遮蔽
ttyd 連線後需要發送 auth token JSON frame 完成認證，整個邏輯未實作 — FakeWebSocketChannel 的 ready 立即完成不需認證，test 永遠看到連線成功
- Test data 代表性
手寫 vs 錄製 vs 生成三種測試資料來源 — 測試資料的代表性是一個隱性假設，決定了 test 能發現什麼問題
- WebSocket 協議測試實作
對真實 ttyd 驗證 frame type 和 auth handshake — 從 T.C1 和 T.C2 的教訓推導出的 protocol integration test 設計
- 功能規格中的 log 點定義方法
把 log 點設計從 debug 階段前移到功能規格階段 — 每個功能的規格文件新增可觀測性欄位，列出啟動 / 步驟 / 錯誤 / 完成四類 log 點
- 導航路徑 test
Back 按鈕、route 可達性、go vs push 語意 — 驗證使用者能從任何畫面回到預期的位置
- 5.2 testing 基礎
用 testing package 驗證函式行為
- 5.2 WebSocket integration test
驗證 client/server 實際互動
- 「名義 integration test」的識別與修正
test 名稱含 integration 但核心依賴全用 fake — 如何辨認、為什麼有害、怎麼修正命名和測試策略
- Assertion 品質三問
斷言的是行為嗎？能區分正確和錯誤嗎？會 flaky 嗎？— 三個問題判斷 assertion 是否有效
- HTTP contract test 設計
HTTP REST API 的 protocol integration test — request/response 格式、status code 語意、error body 結構的驗證
- Playwright 瀏覽器驗證流程
用 Playwright 驗證 web 版本的 UI 行為 — test 結構、selector 策略、和 widget test 的互補關係
- T.C3 ANSI parser 測試資料不覆蓋真實 shell output
ANSI parser 只處理基本 SGR 色彩碼、unit test 用手寫乾淨字串驗證 — 真實 zsh prompt 送出 OSC 標題設定、CSI private mode 游標隱藏、括號貼上模式等數十種控制序列，全部殘留為亂碼
- 名義 Integration Test
名稱含 integration 但核心依賴全用 fake 的 test，驗證內部狀態機而非真實服務互動
- 自架 log endpoint vs 商業方案的取捨判斷
自用工具用自架 log receiver（20 行 Go + grep）、商業 app 用 Sentry/Crashlytics — 判斷依據是使用者規模和 debug 需求
- 5.3 race condition 檢查
用 go test -race 找資料競爭
- 5.3 table-driven test
用表格整理多組輸入、預期輸出與錯誤情境
- 5.3 unittest 基礎
撰寫第一個單元測試
- Hyprland VM 環境設定與測試矩陣
要在 VM 裡測試 Hyprland 配置、或判斷某個設定該在 VM 還是實機驗證時回來讀
- 「事後補 log」vs「設計產物 log」的品質差異
事後補的 log 是救火工具、設計產物的 log 是可觀測性基礎設施 — 從 app_tunnel 的 W2 hotfix log 拆解兩者在格式、覆蓋率、維護成本上的差異
- CI 中的服務 fixture 管理
在 CI 中啟動和停止真實服務的 test harness 設計 — Process.start / Docker / testcontainers 三種方案的適用場景
- Flaky test 根因分類
計時依賴 / 環境差異 / 資源競爭 / 非確定性輸出 — 四類 flaky test 根因的辨識和處理策略
- Screen State Test
驗證使用者可見的畫面狀態覆蓋度和狀態間轉換完整性的 test 層級
- T.C4 Client-side log 缺失導致 debug 只能靠實機盲測
Flutter app 六個核心元件中只有兩個有 log（且全是 W2 hotfix 補的），連線失敗時開發者無法從任何 log 判斷失敗發生在哪一步 — 被迫用最昂貴的 debug 方式：插拔裝置反覆測試
- 判斷原則：什麼時候需要 protocol integration test
從服務架構特徵判斷是否需要 protocol integration test 的決策流程 — 協議複雜度、mock 寬鬆度、失敗靜默度三個維度
- 螢幕截圖比對
Visual regression testing — 用螢幕截圖比對偵測非預期的視覺變化、baseline 管理和 diff 閾值設定
- 5.4 HTTP handler 測試
用 httptest 驗證 request 與 response
- 5.4 table-driven test 的設計邊界
避免測試資料混雜太多概念
- 5.4 Mock 與測試隔離
隔離外部依賴
- 反模式：用 mock 數量彌補 mock 盲區
為什麼增加 mock test 數量無法跨越 mock 的結構性盲區 — 從 192 個 test 全過的案例拆解數量與覆蓋率的真正關係
- 成本判斷表
什麼時候值得寫 protocol integration test、什麼時候用 contract test 或實機測試替代 — 根據服務啟動成本和協議複雜度判斷
- 開發環境 vs 真機的 gate 行為差異表
模擬器、debug build、test 環境中的 gate 行為和真機 release build 不同 — 差異表讓開發者在上機前知道哪些 gate 還沒被真實驗證
- 5.5 時間注入與 deterministic test
用 time provider 避免測試依賴真實時間
- 5.6 並發行為測試
測試 channel、goroutine 與狀態更新
- 7.6 CI、fuzz、load test 與 chaos testing
把單元測試與整合測試擴展成服務可靠性驗證流程
- 5.7 錯誤處理與測試在高併發服務中的角色
把錯誤路徑、測試保護與並發行為放進服務可靠性觀點
- 用前端測試把排版問題自動化
排版問題傳統靠人眼檢查、容易遺漏邊界 case。當一個版型被 debug 兩次以上、就值得寫成 playwright 測試把規範固定下來。本文展開測試替代手動檢查的時機。
- 新增欄位忘記同步 reset — 跨測試狀態洩漏的系統性根因
測試結果取決於執行順序、看似功能 bug 實為上一個 test case 狀態沒清乾淨。根因是新增 private 欄位時沒同步更新 reset，隱含契約沒被顯性化。
- 10 個 Ticket、57 個綠燈、0 條追溯：從需求文件到測試的銜接檢討
單元測試全綠、卻答不出「這些測試覆蓋了哪些 UseCase 場景」。需求到測試缺反向追溯時的流程缺口盤點與對應修法（追溯矩陣、存根策略、拆分規則）。
- 192 個測試全過、實機全壞：Mock 遮蔽真實行為的三層測試策略
unit test 全綠、實機部署後功能整片壞掉。mock-only 策略的結構盲區（text vs binary frame、缺 auth handshake、ANSI 多樣性被 FakeWebSocketChannel 遮蔽），以及分層測試各抓什麼、各遮蔽什麼。
- Firestore Security Rules Test Lab
用 @firebase/rules-unit-testing 在 emulator 上把 Security Rules 寫成自動化測試：放行 / 越權拒絕 / 未登入拒絕 / 欄位竄改拒絕四類斷言、firebase emulators:exec 在 CI 跑、把規則測試接進 release gate
- SQLite Test Fixture Best Practice
SQLite 作為 test fixture、repository contract test、production dialect gap、seed data、fixture snapshot 與 CI evidence 的操作判準
- 測試命名作為文件：可執行的規格說明
測試是少數會自我驗證的文件——名稱跟實際行為不符、CI 會炸。把測試命名寫成 state-based / scenario-based / failure-mode 三種模式的 spec 條目、配合 group 結構作為命名空間、讀者跳到測試檔掃名字就能取代讀 doc。
- Playwright in the Development Loop — 開發循環的三個位置
frontend-with-playwright reference：Playwright 三個位置（假設 / 行為 / 互動驗證）的 evaluate 範例、寫成 layout test 的時機與模板、最低門檻 setup。