Respuesta.

Trabajar con tiempos de espera dinámicos es una tarea crucial en el ámbito de la automatización de UI, especialmente para aplicaciones web modernas, donde el contenido a menudo aparece y cambia no instantáneamente.

Historia del problema En las primeras versiones de la automatización, se utilizaban esperas rígidas (sleep), que hacían que las pruebas fueran demasiado lentas o inestables, si las aplicaciones tardaban más de lo habitual en cargar. Esto se volvió relevante en la era de las SPA y JavaScript pesado.

Problema El uso de retardos estáticos conduce a pruebas inestables y pérdida de tiempo: una prueba automatizada puede ralentizarse o "fallar" aleatoriamente. Además, se afecta la escalabilidad y el mantenimiento de las pruebas.

Solución Usar esperas dinámicas (explícitas): por ejemplo, WebDriverWait en Selenium, funciones waitFor en los frameworks Cypress y Playwright.

from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)  # espera máxima de 10 segundos
wait.until(EC.visibility_of_element_located((By.ID, 'my-element')))

Características clave:

Utilizar esperas explícitas solo donde es necesario
No duplicar esperas para el mismo evento
Definir claramente las condiciones que concluyen la espera (visibility/clickable/etc.)

Preguntas capciosas.

¿Para qué sirve sleep, si hay esperas dinámicas?

El uso de time.sleep() está justificado solo para depuración o en casos extremos. En pruebas automatizadas reales, es mejor hacer siempre esperas explícitas.

¿Puede el uso de esperas eliminar completamente los flakies?

No, si las condiciones de espera se describen de manera inadecuada (por ejemplo, esperando que aparezca un atributo, en lugar de que se carguen completamente los datos), los flakies permanecerán.

¿Se puede hacer una única espera global para todas las pruebas?

No, las condiciones para la aparición de elementos varían. Las esperas deben aplicarse estrictamente a aquellos pasos donde sea necesario.

Errores comunes y anti-patrones

Uso de sleep en lugar de esperas
Repetir esperas donde no son necesarias
Tiempos de espera demasiado largos, que impiden capturar errores reales

Ejemplo de la vida real

Caso negativo

Todas las pruebas automatizadas se escribieron con sleep(2) entre el "clic" y la verificación. Después de actualizar la página, los usuarios se quejaron de retrasos, y las pruebas a veces fallaban debido a la lenta conexión a Internet.

Pros:

Sin código de esperas, las pruebas son simples

Contras:

Las pruebas tardan mucho
Caídas flakies
No se adaptan a la velocidad real de la aplicación

Caso positivo

Se establecieron esperas explícitas para la carga de bloques, el clic se volvió posible después de que aparecieron los elementos necesarios. Se abandonó sleep, todas las pruebas pasan de manera estable y rápida.