在 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 响应和存储的表。
- 确认字段类型和架构版本。
- 运行查找事件的最小查询。
- 根据政策删除或使灯具失效。
不要仅仅因为缺少新引入的分析变量而导致应用程序启动失败。首先推出配置，保留现有行为作为后备，并仅在验证每个已部署环境后强制执行。