Prueba la instrumentación de Telemetry en CI
La instrumentación Telemetry es el comportamiento de la aplicación y debe probarse como cualquier otro límite de integración. Un conjunto de CI útil demuestra que el resultado correcto del terminal crea el evento correcto, el contenido prohibido permanece fuera, la falla de entrega no corrompe el resultado de la aplicación y el SQL operativo aún devuelve el resultado esperado.
No haga que CI dependa de la producción Telemetry API. Inyecte un receptor de eventos o transporte HTTP y capture cargas útiles en la memoria.
Probar el contrato del evento
Cree eventos en una función para que las reglas del esquema sean revisables:
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 } : {}),
};
}
Las pruebas unitarias deben afirmar nombres y tipos de campos exactos, valores de categorías controlados, unidades explícitas y requisitos condicionales. Prefiera afirmaciones de objetos exactos a instantáneas que los revisores puedan actualizar sin notar un cambio semántico.
Ejercite cada ruta terminal
Para el flujo de trabajo propietario, cubra:
- éxito
- fracaso empresarial esperado
- tiempo de espera de dependencia
- reintento seguido de éxito
- reintentos agotados
- cancelación o transferencia humana cuando corresponda
- entrega duplicada
- falta contexto opcional
Afirmar el grano. Se debe emitir un evento de solicitud lógica una vez incluso si la implementación vuelve a intentarlo internamente. Un evento de intento debe incluir un número de intento y una ID de operación lógica estable.
Hacer cumplir el límite de privacidad
Cree dispositivos hostiles que contengan un encabezado de autorización, una cookie, un correo electrónico, una consulta de URL sin formato, un cuerpo de solicitud, un mensaje, un argumento de herramienta y un mensaje de excepción. Afirme que nadie puede llegar al evento capturado.
Una lista de permitidos es más fácil de probar que una lista de denegados en crecimiento. Si la redacción es una capa alternativa, pruébela por separado y asegúrese de que un campo anidado desconocido no pueda omitirla.
Fallo en la entrega de la prueba
Haga que el receptor falso rechace, agote el tiempo y devuelva una respuesta de límite de velocidad. Confirme que la solicitud sigue su política documentada:
- El análisis del mejor esfuerzo no convierte una operación exitosa del cliente en un error.
- eventos críticos de auditoría o facturación utilizan la ruta duradera aprobada
- los reintentos están limitados y usan idempotencia cuando sea necesario
- las descargas de apagado respetan un plazo
- Las fallas de telemetría son observables sin registrar recursivamente la carga útil fallida.
Ver Entrega de eventos e idempotencia y Procesamiento por lotes, contrapresión y apagado.
Validar SQL con accesorios deterministas
Almacene un pequeño conjunto de datos sintéticos y las filas esperadas para SQL importante. Incluya casos de éxito, fracaso, duplicación, nulo, retraso y marca de tiempo de límite. Una prueba de consulta debería hacer visibles sus reglas de conteo.
El Biblioteca de recetas SQL incluye filas de entrada deterministas y salida esperada, mientras que el Zona de juegos SQL puede ejecutar dispositivos compatibles localmente. Utilice esos patrones para alertas y paneles de control propiedad de las aplicaciones.
Agregar verificación de implementación
CI demuestra el comportamiento del código, no la configuración del tiempo de ejecución. Después de la implementación en un entorno que no es de producción:
- Envíe un evento sintético identificado de forma única.
- Verifique la respuesta HTTP y la tabla almacenada.
- Confirme los tipos de campo y la versión del esquema.
- Ejecute la consulta más pequeña que encuentre el evento.
- Eliminar o caducar el dispositivo según la política.
No falle el inicio de la aplicación simplemente porque falta una variable analítica recién introducida. Implemente la configuración primero, conserve el comportamiento existente como alternativa y aplíquela solo después de que se verifique cada entorno implementado.
Documente el contrato en un plan de seguimiento de eventos, siga el lista de verificación de instrumentación de producción y utilice Solución de problemas de ingesta de eventos cuando falle la verificación de la implementación.