Cómo probar una integración cuando una dependencia responde tarde

Define el tiempo aceptable antes de probar. Cada dependencia necesita un presupuesto de latencia basado en la experiencia completa. Un servicio puede responder en veinte segundos y ser aceptable para una tarea en segundo plano, pero inutilizable dentro de un formulario. Establece umbrales para respuesta rápida, lenta y expirada. También define qué ve el usuario en cada estado. Sin criterios previos, el equipo ajusta el juicio después de observar el resultado y puede normalizar demoras que contradicen la promesa del producto.

Simula retrasos de manera controlada. Configura un entorno de prueba donde la dependencia responda después de distintos intervalos, no solo con éxito inmediato o error total. Incluye variación y respuestas que llegan después de que la aplicación ya declaró un timeout. El objetivo es observar colas, pantallas, registros y acciones secundarias. Una integración puede parecer estable durante una prueba simple y producir duplicados cuando la respuesta tardía coincide con un reintento. La latencia revela problemas de coordinación que un fallo instantáneo no muestra.

Diseña estados visibles para el usuario. Evita dejar una pantalla congelada o mostrar un error definitivo mientras el proceso todavía continúa. Utiliza estados como recibido, procesando, esperando proveedor, completado y requiere intervención. Explica qué puede hacer la persona y cuándo recibirá una actualización. Si el usuario repite la acción por incertidumbre, el sistema debe reconocer la solicitud original. La comunicación forma parte de la confiabilidad porque reduce comportamientos que aumentan carga y generan operaciones duplicadas.

Prueba reintentos con idempotencia. Un reintento no debe crear dos pagos, mensajes, citas o registros. Asigna una clave única a la operación y exige que la dependencia o la capa intermedia reconozca solicitudes repetidas. Simula pérdida de respuesta después de que la acción ya fue ejecutada, uno de los escenarios más peligrosos. El sistema debe consultar estado antes de repetir. También define número máximo, espera entre intentos y condición para detenerse. Reintentar sin límites puede convertir una demora temporal en saturación.

Separa la experiencia de la dependencia. Cuando sea posible, acepta la solicitud, conserva datos y procesa de forma asíncrona. El usuario recibe confirmación de recepción sin esperar a que todos los servicios terminen. Esta arquitectura no aplica a cada caso, especialmente cuando la decisión depende de una respuesta inmediata, pero reduce acoplamiento. Necesita colas, estados y reconciliación. La prueba debe verificar que los trabajos no se pierden al reiniciar y que una persona puede identificar y resolver los que quedan detenidos.

Incluye respuestas incompletas y fuera de orden. Una dependencia lenta puede devolver parte de la información o enviar eventos en una secuencia diferente. Verifica que la aplicación no marque completado antes de tener los campos necesarios y que pueda incorporar una actualización tardía. También prueba reloj, zonas horarias y expiraciones. Los registros deben mostrar cuándo se envió, cuándo respondió y qué versión del dato se utilizó. Sin esa línea de tiempo, investigar una incidencia de latencia se convierte en comparar capturas y suposiciones.

Cierra con una prueba de recuperación. Desconecta la dependencia, acumula solicitudes y restáurala. Observa orden, velocidad, duplicados y comunicación. Define cuándo el sistema necesita intervención humana y cómo se reanudan los casos. Documenta métricas de tiempo y pérdida. Una integración confiable no es la que siempre recibe respuestas rápidas, sino la que mantiene consistencia cuando una parte se retrasa. Probar la demora antes del lanzamiento permite diseñar estados, límites y recuperación sin que el primer experimento ocurra frente a clientes reales.