Uno de los mayores desafíos de las pruebas End-to-End es la inestabilidad. Una prueba inestable es aquella que a veces pasa y a veces falla sin que haya cambiado el comportamiento real que queremos validar.
Muchas veces estas fallas aparecen por problemas de sincronización: la prueba intenta hacer una acción antes de que la pantalla esté lista, antes de que termine una petición, antes de que aparezca un elemento o antes de que el sistema actualice su estado.
En este tema veremos qué son las esperas, por qué las pruebas se vuelven inestables y cómo diseñar escenarios E2E más confiables.
Sincronizar una prueba significa coordinar sus acciones con el estado real de la aplicación. La prueba debe esperar a que el sistema esté preparado antes de continuar.
Por ejemplo, después de presionar "Confirmar compra", la prueba no debería buscar inmediatamente el mensaje de éxito si el backend todavía está procesando el pago. Debe esperar una señal clara: mensaje visible, cambio de página, orden creada o estado actualizado.
Una prueba inestable, también llamada flaky test, produce resultados inconsistentes. Puede fallar en una ejecución y pasar en la siguiente sin cambios en el código.
Ejemplos de síntomas:
Las pruebas inestables son peligrosas porque reducen la confianza del equipo. Si las fallas se consideran "ruido", se pueden ignorar defectos reales.
Las causas pueden estar en la prueba, en el ambiente o en la aplicación. Algunas de las más comunes son:
| Causa | Ejemplo | Consecuencia |
|---|---|---|
| Carga asincrónica | La pantalla muestra datos después de una petición. | La prueba busca elementos antes de que existan. |
| Esperas fijas | Esperar siempre 2 segundos. | A veces sobra tiempo y a veces no alcanza. |
| Datos compartidos | Dos pruebas usan el mismo usuario o recurso. | Una ejecución altera el estado de la otra. |
| Servicios lentos | Pago, correo o backend responden con demora. | El resultado aparece tarde o no aparece a tiempo. |
| Selectores frágiles | La prueba depende de una clase CSS cambiante. | Falla aunque el comportamiento sea correcto. |
| Animaciones | Un elemento existe, pero todavía no puede recibir clic. | La acción se ejecuta en un momento incorrecto. |
Una espera fija consiste en pausar la prueba durante una cantidad determinada de tiempo, por ejemplo tres segundos. Aunque parece una solución rápida, suele ser una fuente de problemas.
Problemas de las esperas fijas:
Una espera basada en condición espera hasta que ocurra algo específico. Es más clara y más estable que una pausa fija.
Ejemplos de condiciones útiles:
La condición debe estar conectada con el flujo. No se trata de esperar cualquier elemento, sino la señal que indica que el sistema está listo para el siguiente paso.
Que un elemento esté visible no siempre significa que esté listo para interactuar. Puede estar cubierto por una animación, deshabilitado, cargando datos o esperando una respuesta del servidor.
Antes de interactuar, puede ser necesario confirmar:
Por ejemplo, un botón "Confirmar" puede verse en pantalla, pero estar deshabilitado hasta que se calcule el total de la compra.
En aplicaciones modernas, muchas acciones dependen de peticiones al backend. La pantalla puede cambiar después de que una API responda, no necesariamente en el instante del clic.
Ejemplos:
Una prueba E2E debe esperar una consecuencia de esas respuestas: datos visibles, mensaje final, cambio de estado o navegación esperada.
A veces el elemento visual aparece, pero el estado del negocio todavía no está listo. Por ejemplo, después de enviar una solicitud puede aparecer un mensaje, pero el estado real todavía no fue actualizado por un proceso interno.
En escenarios críticos, conviene verificar señales de negocio:
Esto permite que la prueba espere el resultado que realmente importa, no solo un cambio superficial de pantalla.
Un timeout es el tiempo máximo que una prueba espera antes de declarar que algo falló. Los timeouts son necesarios, pero deben elegirse con criterio.
| Timeout demasiado corto | Timeout demasiado largo |
|---|---|
| Genera fallas por demoras normales del ambiente. | Hace que una falla real tarde mucho en reportarse. |
| Vuelve la prueba sensible a pequeñas variaciones. | Alarga innecesariamente la suite. |
| Puede fallar en ambientes más lentos. | Puede ocultar problemas de rendimiento o bloqueo. |
El objetivo es dar tiempo razonable para que la condición ocurra, sin convertir las fallas en esperas interminables.
La inestabilidad no siempre viene de la interfaz. También puede aparecer cuando varias pruebas comparten datos y se ejecutan al mismo tiempo.
Ejemplos:
Para evitarlo, conviene crear datos únicos por ejecución o separar recursos por escenario.
Un ambiente puede responder de forma diferente según carga, red, servicios externos o recursos disponibles. Si las pruebas dependen de tiempos exactos, serán inestables.
Señales de ambiente variable:
En estos casos conviene revisar capacidad del ambiente, aislamiento de datos y dependencias externas.
Cuando una prueba falla de manera intermitente, no conviene ignorarla ni simplemente repetirla muchas veces. Es mejor investigar la causa.
Pasos útiles:
El objetivo es convertir una falla intermitente en una causa concreta y corregible.
Algunas prácticas ayudan a construir pruebas E2E más estables:
Supongamos una prueba que falla porque, después de confirmar una compra, busca inmediatamente el texto "Compra realizada". A veces el mensaje aparece rápido y la prueba pasa. Otras veces el backend tarda más y la prueba falla.
Una versión frágil sería:
Una versión más estable sería:
La segunda opción espera señales del flujo y verifica una consecuencia más fuerte.
Al tratar sincronización y esperas, conviene evitar estos errores:
La sincronización es uno de los factores que más afecta la confiabilidad de las pruebas End-to-End. Una prueba que avanza antes de tiempo puede fallar aunque el sistema funcione correctamente.
Para reducir inestabilidad, las pruebas deben esperar señales reales del sistema, usar datos controlados, evitar dependencias innecesarias y producir evidencias útiles cuando algo falla.
En el próximo tema veremos selectores, identificadores y elementos confiables para pruebas E2E.