Muchas pruebas End-to-End no recorren solamente nuestra aplicación. También atraviesan servicios externos: proveedores de correo, pasarelas de pago, servicios de autenticación, APIs de mapas, sistemas de notificación, almacenamiento de archivos o plataformas de terceros.
Estas dependencias pueden aportar realismo al escenario, pero también pueden volver la prueba lenta, costosa o inestable. Si un servicio externo responde tarde, cambia su comportamiento o queda fuera de servicio, una prueba E2E puede fallar aunque nuestra aplicación esté funcionando correctamente.
En este tema veremos cómo decidir cuándo usar servicios reales, cuándo usar ambientes de prueba, cuándo simular una dependencia y qué verificar en flujos que involucran correos, pagos y proveedores externos.
Una dependencia externa es cualquier sistema que participa en el flujo, pero que no controlamos completamente desde nuestra aplicación ni desde nuestra suite de pruebas.
Algunos ejemplos habituales son:
Una prueba E2E busca dar confianza sobre un flujo completo. Pero cuando depende de un tercero, una falla puede tener varias causas posibles: un defecto en nuestra aplicación, una configuración incorrecta, un problema de red, una caída del proveedor o un cambio en el ambiente externo.
Riesgos comunes:
Por eso las dependencias externas deben ser parte explícita del diseño del escenario, no un detalle accidental.
Usar el servicio real puede parecer la opción más completa, pero no siempre es la mejor. En muchas pruebas E2E conviene validar nuestra aplicación con una versión controlada de la dependencia, especialmente si el tercero es lento, costoso, cambiante o difícil de limpiar.
| Opción | Qué aporta | Riesgo |
|---|---|---|
| Servicio real productivo | Máximo realismo. | Puede generar efectos reales, costos y datos difíciles de revertir. |
| Ambiente sandbox del proveedor | Comportamiento parecido al real sin impacto productivo. | Puede tener diferencias con producción o disponibilidad limitada. |
| Servicio simulado | Control, velocidad y respuestas predecibles. | No valida la integración real con el proveedor. |
| Prueba manual puntual con el tercero | Confirma casos críticos sin ejecutar todo el tiempo. | No cubre regresión frecuente de manera automática. |
Un ambiente sandbox es un entorno de prueba provisto por un tercero. Permite interactuar con el servicio sin afectar operaciones reales. Es común en pasarelas de pago, APIs de facturación, proveedores de identidad y servicios financieros.
Un sandbox puede ofrecer:
Aunque el sandbox es útil, no debemos asumir que es idéntico a producción. Conviene documentar sus diferencias y cubrir la integración real con alguna validación controlada antes de liberar cambios importantes.
Simular una dependencia significa reemplazar el servicio externo por una respuesta controlada. En algunos contextos se habla de mock, stub o fake. Las diferencias técnicas entre esos términos pueden variar, pero la idea central es que la prueba no depende del proveedor real para avanzar.
Esta estrategia es útil cuando necesitamos probar muchas variantes: pago aprobado, pago rechazado, correo enviado, proveedor caído, respuesta lenta, usuario sin permisos o token inválido.
La decisión depende del objetivo de la prueba. Si queremos validar reglas internas de nuestra aplicación frente a distintas respuestas, simular suele ser adecuado. Si queremos validar que la conexión con el proveedor funciona, necesitamos una prueba de integración o una E2E controlada contra el ambiente del proveedor.
| Objetivo | Estrategia recomendada |
|---|---|
| Comprobar que la aplicación muestra error si el pago es rechazado. | Simular respuesta rechazada. |
| Comprobar que las credenciales del proveedor siguen funcionando. | Probar contra sandbox o ambiente real controlado. |
| Validar muchas combinaciones de estados de un proveedor. | Simular respuestas para cubrir variantes. |
| Confirmar que se interpreta correctamente un webhook real. | Usar sandbox o prueba de contrato del proveedor. |
| Verificar una pantalla de confirmación propia. | Simular el resultado externo y validar la UI local. |
Muchos flujos dependen de correos: registro de cuenta, recuperación de contraseña, confirmaciones de compra, invitaciones, facturas, avisos de cambio de estado o validación de identidad.
En una prueba E2E no conviene enviar correos reales a usuarios reales. Lo recomendable es usar una bandeja de prueba, un servicio de captura de correos o un servidor SMTP controlado por el ambiente.
Una estrategia de correo para E2E debe permitir:
El correo puede tener diseño, textos comerciales o contenido variable. La prueba debe verificar lo que realmente forma parte del flujo.
| Verificación útil | Verificación frágil |
|---|---|
| El correo llega al destinatario de prueba correcto. | El correo tiene exactamente el mismo HTML completo. |
| El asunto identifica la acción esperada. | El asunto coincide con una frase promocional cambiante. |
| El enlace de activación permite continuar el flujo. | El enlace aparece en una posición exacta del diseño. |
| El número de orden o dato clave está presente. | Todos los saltos de línea coinciden exactamente. |
Los pagos son una de las dependencias externas más sensibles. Un flujo de pago puede involucrar tarjetas, billeteras, validaciones antifraude, redirecciones, webhooks, estados pendientes, rechazos y confirmaciones asincrónicas.
En pruebas E2E se deben evitar cargos reales. Lo habitual es usar tarjetas de prueba, credenciales sandbox y montos ficticios. También conviene separar los escenarios de pago en objetivos claros.
Ejemplos de escenarios:
En un pago, una pantalla de éxito no siempre alcanza. Puede existir una demora entre la confirmación visible y el cambio definitivo de estado en el sistema. Además, algunos proveedores notifican el resultado mediante webhooks o procesos asincrónicos.
Una prueba bien diseñada puede verificar:
Muchos servicios externos no responden todo en el momento de la acción. En su lugar, envían una notificación posterior, llamada webhook, o actualizan el estado después de algunos segundos.
Esto afecta el diseño de la prueba. No conviene asumir que el estado final estará disponible inmediatamente. Se necesita una espera basada en condición: por ejemplo, esperar hasta que la orden pase a estado pagada o hasta que aparezca el correo esperado.
Buenas prácticas:
Algunas aplicaciones usan proveedores externos para iniciar sesión: cuentas corporativas, Google, Microsoft, redes sociales, SSO o autenticación multifactor. Estos flujos pueden ser difíciles de automatizar porque incluyen pantallas de terceros, medidas anti-bot, códigos temporales y políticas de seguridad.
Para pruebas E2E conviene evaluar alternativas:
Si cada prueba necesita pasar por un login externo complejo, la suite puede volverse lenta y frágil.
Algunos proveedores tienen límites de solicitudes, costos por uso o políticas contra automatizaciones repetidas. Una suite E2E puede ejecutar decenas o cientos de veces por día, por lo que no debe depender sin control de servicios que cobran o bloquean por volumen.
Conviene revisar:
El costo y la estabilidad también forman parte de la calidad de la estrategia E2E.
Los datos usados con servicios externos deben ser controlados. No conviene reutilizar cuentas reales, tarjetas reales, direcciones de correo personales ni teléfonos de personas del equipo.
Buenas prácticas:
Una prueba confiable necesita datos que no se mezclen con ejecuciones anteriores ni con usuarios reales.
Una aplicación bien diseñada debe comportarse correctamente cuando una dependencia externa falla. Las pruebas E2E pueden validar algunos de estos casos, especialmente si se simula la respuesta del proveedor.
| Falla externa | Comportamiento esperado |
|---|---|
| El proveedor no responde. | La aplicación muestra un error recuperable y no confirma la operación indebidamente. |
| El pago es rechazado. | La orden no queda pagada y el usuario recibe una explicación clara. |
| El correo no puede enviarse. | El sistema registra el problema y permite reintentar si corresponde. |
| El token externo es inválido. | El usuario no obtiene acceso y se informa la necesidad de autenticarse nuevamente. |
| El servicio responde datos incompletos. | La aplicación evita estados inconsistentes y muestra una alternativa segura. |
Supongamos un flujo E2E donde un alumno compra un curso. El escenario puede involucrar nuestra aplicación, una pasarela de pago y un servicio de correo.
| Parte del flujo | Dependencia | Estrategia de prueba |
|---|---|---|
| El alumno elige el curso y confirma compra. | Aplicación propia. | Validar con UI y datos únicos de prueba. |
| El pago se procesa. | Pasarela externa. | Usar sandbox o simular respuesta aprobada. |
| La orden cambia de estado. | Backend propio y evento externo. | Esperar hasta que la orden figure como pagada. |
| El curso queda disponible. | Aplicación propia. | Verificar que aparece en "Mis cursos". |
| Se envía confirmación. | Servicio de correo. | Leer bandeja de prueba y verificar datos clave. |
No todas las verificaciones relacionadas con un proveedor deben estar en la misma prueba E2E. Puede ser más claro separar responsabilidades.
Por ejemplo:
Esta separación permite cubrir más riesgos sin hacer que todos los escenarios dependan siempre del proveedor real.
Al manejar dependencias externas en pruebas E2E, conviene evitar estos errores:
Antes de agregar una dependencia externa a una prueba E2E, podemos revisar:
Las dependencias externas son una parte inevitable de muchos flujos End-to-End. Correos, pagos, autenticación y servicios de terceros suelen ser necesarios para representar escenarios reales, pero deben manejarse con cuidado.
Una buena estrategia combina ambientes sandbox, simulaciones controladas y algunas validaciones reales bien elegidas. Así la suite puede ser confiable, económica y útil para detectar problemas importantes sin fallar constantemente por factores fuera del control del equipo.
En el próximo tema veremos evidencias de ejecución: capturas, videos, trazas y registros.