Muchas aplicaciones necesitan comunicarse con sistemas externos: pasarelas de pago, servicios de correo, proveedores de identidad, plataformas de facturación, servicios logísticos, APIs de mapas o sistemas de otras organizaciones.
Estas integraciones agregan riesgo porque parte del comportamiento queda fuera del control directo del equipo. El sistema externo puede cambiar, fallar, responder lento, rechazar datos o tener reglas propias.
En este tema veremos cómo pensar pruebas de integración con APIs y sistemas externos de manera segura, controlada y útil.
Un sistema externo es una dependencia que no pertenece completamente al sistema que estamos desarrollando. Puede ser mantenido por otro equipo, otra empresa o una plataforma de terceros.
Esto implica que:
En una integración con un sistema externo, las pruebas pueden verificar:
El contrato de una API externa define cómo debemos comunicarnos con ella. Puede estar documentado por el proveedor o expresado mediante ejemplos, especificaciones o SDKs.
Conviene revisar:
Una prueba de integración debe confirmar que nuestra aplicación cumple ese contrato y puede interpretar las respuestas esperadas.
Muchas APIs externas requieren autenticación. Puede tratarse de tokens, claves de API, certificados, usuarios de servicio u otros mecanismos.
Las pruebas deben considerar:
Un error de autenticación puede parecer una falla funcional si la prueba no registra suficiente evidencia.
Muchos proveedores ofrecen un ambiente sandbox, es decir, un entorno de prueba separado de producción. Allí se pueden simular operaciones sin afectar datos reales.
Un sandbox es útil para:
Sin embargo, un sandbox también puede comportarse distinto de producción. Por eso sus limitaciones deben conocerse.
En muchas pruebas de integración conviene reemplazar el sistema externo por una simulación controlada. Esto permite ejecutar casos de éxito, error, demora o respuesta inválida sin depender del proveedor real.
Una simulación puede ayudar a probar:
El riesgo es que la simulación quede desactualizada. Por eso debe mantenerse alineada con el contrato real.
La elección depende del objetivo de la prueba. No existe una única respuesta correcta para todos los casos.
| Opción | Uso adecuado | Cuidado |
|---|---|---|
| Servicio real | Validar máxima compatibilidad en un ambiente controlado. | Puede tener costos, riesgos y variabilidad. |
| Sandbox | Probar integración contra proveedor sin afectar producción. | Puede no reproducir todos los casos reales. |
| Simulación | Controlar respuestas y ejecutar pruebas repetibles. | Debe respetar el contrato actualizado. |
Una integración externa debe manejar errores de forma clara. No basta con probar el camino exitoso.
Conviene probar qué ocurre cuando el proveedor:
La prueba debe verificar que nuestra aplicación informe el problema y mantenga un estado interno coherente.
Los sistemas externos pueden tardar en responder. La configuración de timeout y reintentos influye directamente en el comportamiento de la integración.
Una prueba de integración puede verificar:
Este punto es especialmente importante en pagos, reservas, creación de órdenes y cualquier operación con efectos externos.
Cuando una operación puede reintentarse, la idempotencia es clave. Repetir la misma solicitud no debería producir efectos duplicados si la operación representa la misma intención.
Ejemplos de problemas:
Las pruebas deben verificar cómo se usan identificadores de operación, claves de idempotencia o controles internos para evitar duplicados.
Una llamada a un sistema externo puede producir efectos secundarios reales: enviar un correo, cobrar dinero, reservar stock, emitir una factura o crear un expediente.
En pruebas de integración, debemos evitar efectos peligrosos:
La seguridad del ambiente es parte del diseño de la prueba.
Cuando una integración externa falla, necesitamos evidencia. El proveedor puede devolver un identificador de transacción, código de error o mensaje que ayude a diagnosticar.
Conviene registrar:
Los logs deben ser útiles, pero no deben exponer secretos, tokens ni datos sensibles innecesarios.
Supongamos una integración con una pasarela de pagos. Algunas pruebas importantes serían:
| Escenario | Qué se verifica |
|---|---|
| Pago aprobado | La orden queda pagada y se registra el identificador del proveedor. |
| Pago rechazado | La orden no queda confirmada y no se descuenta stock indebidamente. |
| Timeout | La operación queda pendiente o se informa error según la regla definida. |
| Reintento | No se duplica el cobro ni la orden. |
| Credencial inválida | El error se registra y se informa de forma controlada. |
Para un servicio de correo, las pruebas pueden enfocarse en que la aplicación solicite el envío correcto, sin enviar mensajes reales en cada ejecución.
Se puede verificar:
Un servidor de correo falso o una simulación puede capturar mensajes para inspeccionarlos sin contactar usuarios reales.
Al integrar APIs y sistemas externos, suelen aparecer errores como:
Antes de confiar en una integración externa, conviene revisar:
Las APIs y sistemas externos son puntos críticos de integración porque combinan contratos, red, seguridad, datos y efectos fuera del control directo del equipo.
Una buena prueba de integración externa debe ser segura, repetible y clara sobre qué dependencia está usando: real, sandbox o simulada. También debe verificar el estado interno de nuestra aplicación después de cada respuesta importante.
En el próximo tema veremos las pruebas de contratos entre productores y consumidores.