No todas las integraciones ocurren de forma inmediata. En muchos sistemas, un componente publica un mensaje o evento y otro lo procesa más tarde. Este tipo de integración se conoce como comunicación asíncrona.
Las colas, eventos y procesos asíncronos permiten desacoplar partes del sistema, pero también agregan desafíos para las pruebas: tiempos de espera, duplicados, orden de mensajes, reintentos, errores y consistencia eventual.
En este tema veremos cómo pensar pruebas de integración para este tipo de escenarios.
En una comunicación síncrona, un componente llama a otro y espera una respuesta inmediata. En una comunicación asíncrona, un componente deja un mensaje para que otro lo procese después.
| Tipo | Cómo funciona | Ejemplo |
|---|---|---|
| Síncrona | El consumidor espera una respuesta en el momento. | Consultar stock antes de confirmar una compra. |
| Asíncrona | El productor publica un mensaje y otro componente lo procesa luego. | Enviar correo después de crear una orden. |
Una cola es un mecanismo donde un productor deja mensajes y uno o más consumidores los procesan. La cola permite que el productor no dependa de que el consumidor esté disponible en ese mismo instante.
En pruebas de integración, una cola puede usarse para verificar:
Un evento representa algo que ocurrió en el sistema. Por ejemplo: usuario registrado, orden creada, pago aprobado, stock actualizado o archivo importado.
Un evento debería comunicar un hecho relevante, no una instrucción detallada de cómo debe actuar el consumidor.
Un evento suele incluir:
En una integración asíncrona, el productor publica el mensaje o evento. El consumidor lo lee y ejecuta alguna acción.
Las pruebas pueden enfocarse en:
No siempre es necesario probar todo junto en cada caso. El alcance debe elegirse según el riesgo.
Una prueba de integración puede verificar que una operación publique un mensaje esperado.
Por ejemplo, al crear una orden, podemos comprobar que se publique un evento con:
orden_creada.La prueba debe verificar estructura y contenido, no solo que haya “algún mensaje” en la cola.
Otra prueba puede enfocarse en el consumidor. En ese caso, se prepara un mensaje conocido y se verifica que el consumidor lo procese correctamente.
Por ejemplo, un consumidor de notificaciones debería:
Este enfoque permite probar el consumidor aunque el productor todavía no esté disponible.
En algunos casos conviene probar el flujo completo: una operación produce un evento, el evento llega a la cola, el consumidor lo procesa y el estado final se verifica.
Este tipo de prueba da más confianza, pero también puede ser más lenta y difícil de diagnosticar.
Debe definir claramente:
Una dificultad habitual en pruebas asíncronas es esperar a que el resultado aparezca. Usar pausas fijas, como esperar siempre cinco segundos, puede hacer las pruebas lentas e inestables.
Es mejor usar esperas controladas:
La prueba debe distinguir entre una demora normal y una falla real del proceso.
En sistemas con colas, un mensaje puede llegar más de una vez. El consumidor debe estar preparado para no generar efectos duplicados peligrosos.
Una prueba puede verificar que, si el mismo evento se procesa dos veces:
La idempotencia es una propiedad importante en consumidores de eventos.
Algunos sistemas garantizan orden de mensajes, otros no. Si el consumidor depende de un orden específico, esa expectativa debe estar clara.
Problemas posibles:
Las pruebas de integración pueden incluir casos donde el orden no sea ideal para verificar la robustez del consumidor.
Cuando un consumidor falla al procesar un mensaje, el sistema puede reintentar. Si sigue fallando, puede moverlo a una cola de errores o dejarlo registrado para revisión.
Conviene probar:
El objetivo es evitar que un mensaje problemático bloquee todo el proceso sin evidencia.
En procesos asíncronos, el estado final puede no estar disponible inmediatamente. Esto se llama consistencia eventual: el sistema llega al estado esperado después de cierto tiempo.
Por ejemplo, una orden puede crearse inmediatamente, pero el reporte de ventas puede actualizarse después de consumir un evento.
Las pruebas deben aceptar esta naturaleza asíncrona, pero con límites claros. Esperar indefinidamente no es una buena estrategia.
Las colas deben limpiarse o aislarse para evitar que mensajes viejos afecten pruebas nuevas.
Buenas prácticas:
Un mensaje residual puede hacer que una prueba pase o falle por una razón equivocada.
Supongamos una integración donde el servicio de órdenes publica un evento y el servicio de notificaciones lo consume.
| Paso | Qué se verifica |
|---|---|
| Crear orden. | El productor ejecuta la operación principal. |
| Revisar evento publicado. | El mensaje contiene identificador, cliente y total. |
| Ejecutar consumidor. | El servicio de notificaciones procesa el evento. |
| Verificar estado final. | Existe una notificación asociada a la orden. |
| Limpiar datos. | No quedan mensajes ni registros residuales. |
Al probar colas, eventos y procesos asíncronos, suelen aparecer errores como:
Antes de confiar en una prueba asíncrona, conviene revisar:
Las colas, eventos y procesos asíncronos permiten construir sistemas más desacoplados, pero exigen pruebas de integración cuidadosas. No basta con comprobar que un mensaje se envió: también debemos verificar contenido, consumo, estado final, errores y limpieza.
Una buena prueba asíncrona acepta que el resultado puede tardar, pero define cómo esperarlo, cómo diagnosticar fallas y cómo evitar interferencias entre ejecuciones.
En el próximo tema veremos archivos, almacenamiento y recursos compartidos.