在 CI 中測試 Telemetry 插樁
Telemetry 檢測是應用程式行為，應該像任何其他整合邊界一樣進行測試。有用的 CI 套件證明正確的終端結果會建立正確的事件，禁止的內容會保留在外面，交付失敗不會破壞應用程式結果，並且操作 SQL 仍會返回預期結果。
不要使 CI 依賴於生產 Telemetry API。注入事件接收器或 HTTP 傳輸並捕獲記憶體中的有效負載。
測試事件合約
在一個函式中建置事件，以便可以審查架構規則：
type CheckoutInput = {
checkoutId: string;
status: "success" | "failed";
durationMs: number;
errorType?: "payment_declined" | "provider_timeout";
};
export function checkoutEvent(input: CheckoutInput) {
return {
event_name: "checkout_completed",
schema_version: 1,
checkout_id: input.checkoutId,
status: input.status,
duration_ms: input.durationMs,
...(input.errorType ? { error_type: input.errorType } : {}),
};
}
單元測試應斷言準確的欄位名稱和型別、受控類別值、顯式單位和條件要求。優先選擇精確物件斷言，而不是審閱者可能在沒有注意到語義更改的情況下更新的快照。
鍛鍊每條終端路徑
對於擁有的工作流程，包括：
- 成功
- 預期的商業失敗
- 依賴超時
- 重試後成功
- 重試已耗盡
- 取消或人工切換（如適用）
- 重複投遞
- 缺少可選上下文
斷言穀物。即使實現在內部重試，也應該發出一次邏輯請求事件。嘗試事件應包括嘗試編號和穩定邏輯操作ID。
強化隱私邊界
建立包含授權標頭、cookie、電子郵件、原始 URL 查詢、請求正文、提示、工具參數和異常訊息的惡意裝置。斷言沒有人可以到達捕獲的事件。
允許名單比不斷成長的拒絕名單更容易測試。如果密文是後備層，請單獨測試它並確保未知的巢狀欄位無法繞過它。
測試交付失敗
讓假接收器拒絕、超時並返回速率限制回應。確認應用程式遵循其記錄的政策：
- 盡最大努力分析不會將成功的客戶操作變成錯誤
- 關鍵稽核或計費事件使用批准的持久路徑
- 重試是有限的，並在需要時使用冪等性
- 關閉沖洗遵守最後期限
- 無需遞迴記錄失敗的有效負載即可觀察遙測失敗
請參見 事件傳遞和冪等性 和 批次處理、背壓和關閉。
使用確定性夾具驗證 SQL
儲存一個小型合成資料集和重要的 SQL 的預期行。包括成功、失敗、重複、空、延遲和邊界時間戳情況。查詢測試應該使其計數規則可見。
SQL配方庫 包括確定性輸入行和預期輸出，而 SQL遊樂場 可以在本地執行支援的裝置。將這些模式用於應用程式擁有的儀表板和警示。
新增部署驗證
CI 證明程式碼行為，而不是執行時設定。部署到非生產環境後：
- 傳送唯一標識的合成事件。
- 驗證 HTTP 回應和儲存的資料表。
- 確認欄位型別和架構版本。
- 執行查詢事件的最小查詢。
- 根據政策刪除或使燈具失效。
不要僅僅因為缺少新引入的分析變數而導致應用程式啟動失敗。首先推出設定，保留現有行為作為後備，並僅在驗證每個已部署環境後強制執行。