Cuando una prueba de integración falla, necesitamos evidencia para entender qué ocurrió. Esa evidencia puede estar en logs, mensajes de error, respuestas, estados de base de datos, eventos, archivos generados o capturas del ambiente.
Sin evidencia clara, el diagnóstico se vuelve lento. El equipo puede saber que algo falló, pero no dónde ni por qué.
En este tema veremos cómo usar logs, mensajes de error y evidencias para investigar problemas de integración de forma más efectiva.
La evidencia es cualquier información observable que ayuda a confirmar qué hizo el sistema durante la prueba.
Puede incluir:
Un log útil no es simplemente una gran cantidad de texto. Es información relevante para entender una operación.
Un buen log puede indicar:
Los logs deben ser claros, pero no deben exponer secretos ni datos sensibles innecesarios.
Los sistemas suelen manejar distintos niveles de log. Usarlos correctamente ayuda a separar información normal de problemas reales.
| Nivel | Uso habitual | Ejemplo |
|---|---|---|
| Debug | Detalles para investigación técnica. | Datos principales de una solicitud interna. |
| Info | Eventos normales importantes. | Orden creada correctamente. |
| Warn | Situación anormal, pero controlada. | Proveedor externo no respondió y se reintentará. |
| Error | Falla que impidió completar una operación. | No se pudo registrar el pago. |
Un identificador de correlación permite seguir una operación a través de varios componentes. Es especialmente útil cuando una integración involucra servicios, colas o procesos asíncronos.
Por ejemplo, una compra puede tener un identificador que aparezca en:
Sin un identificador común, reconstruir el flujo puede ser mucho más difícil.
Un mensaje de error debe ayudar a entender qué ocurrió. No siempre debe mostrar detalles técnicos al usuario, pero sí debe permitir que el equipo investigue.
Un buen mensaje de error interno debería indicar:
Mensajes como “error general” o “algo salió mal” son insuficientes para diagnosticar integraciones complejas.
Cuando una integración modifica datos, la base de datos puede ofrecer evidencia fundamental.
Conviene revisar:
La prueba puede incluir consultas de verificación para confirmar el estado final sin depender de inspección manual.
Los servicios simulados no solo devuelven respuestas. También pueden registrar qué solicitudes recibieron.
Esto permite verificar:
Esta evidencia ayuda a diagnosticar errores de contrato, duplicados y configuración.
En integraciones asíncronas, la evidencia puede estar en mensajes publicados, mensajes consumidos o mensajes enviados a una cola de errores.
Conviene observar:
Una prueba asíncrona debe poder distinguir entre “no se publicó”, “se publicó mal” y “se publicó bien pero no se consumió”.
Si una integración genera o procesa archivos, el archivo mismo es evidencia.
La prueba puede conservar o verificar:
Cuando una prueba falla por un archivo inválido, conservar una copia temporal puede facilitar el diagnóstico.
Para diagnosticar una integración, muchas veces necesitamos saber qué entró y qué salió de cada componente.
Esto puede incluir:
La captura debe ser suficiente para investigar, pero debe evitar exponer datos sensibles o secretos.
Guardar evidencia no significa registrar todo sin filtro. Las pruebas pueden manejar contraseñas, tokens, correos, documentos, importes o datos personales.
Cuidados importantes:
La evidencia debe ser útil y segura al mismo tiempo.
Una buena suite puede capturar información adicional cuando una prueba falla. Esto reduce el tiempo necesario para investigar.
Ejemplos:
Esta evidencia automática debe estar enfocada en el escenario, no ser una descarga masiva de información difícil de leer.
Supongamos una prueba donde un pago rechazado deja la orden como pagada por error. Para investigar, necesitamos evidencia como:
| Evidencia | Qué ayuda a entender |
|---|---|
| Respuesta del proveedor simulado | Confirma que el pago fue rechazado. |
| Logs del servicio de compras | Muestra cómo se interpretó la respuesta. |
| Estado de la orden en base de datos | Confirma el estado final incorrecto. |
| Eventos publicados | Indica si se publicó un evento de compra confirmada indebidamente. |
| Identificador de correlación | Permite unir toda la evidencia de la misma operación. |
Si un evento se publica pero el consumidor no genera el resultado esperado, conviene reunir:
Esta evidencia permite distinguir si el problema fue de publicación, transporte, contrato o consumo.
Al trabajar con logs y evidencias, suelen aparecer errores como:
Para mejorar evidencia en pruebas de integración, podemos revisar:
Los logs, mensajes de error y evidencias son herramientas esenciales para investigar fallas de integración. Una prueba fallida debe entregar información suficiente para entender qué ocurrió y dónde comenzar el análisis.
Una suite madura no solo ejecuta pruebas: también ayuda a diagnosticar cuando algo falla.
En el próximo tema veremos automatización básica de pruebas de integración.