Respuesta.

Al principio de la automatización de pruebas de UI, la principal dificultad era la inestabilidad de las pruebas debido a las demoras en la aparición de elementos, así como la necesidad de esperar a que se completaran acciones asíncronas en la página. Anteriormente, los testers a menudo utilizaban demoras rígidas (sleep), lo que llevaba a una larga ejecución de pruebas y baja estabilidad.

El problema radica en que las aplicaciones web están volviéndose cada vez más dinámicas. Los elementos aparecen y desaparecen de forma asíncrona, y el trabajo simultáneo del frontend y backend puede causar situaciones donde las pruebas fallan debido a una espera incorrecta del estado de la UI. Las pausas estáticas, como Thread.sleep(1000), solo aumentan el tiempo de prueba y no garantizan el paso exitoso de la prueba.

La solución es usar esperas explícitas e implícitas (explicit/implicit waits), que permiten sincronizar las acciones de manera más flexible y efectiva con el estado real de la interfaz. Por ejemplo, en Selenium o marcos similares se utilizan WebDriverWait o análogos para verificar la aparición de los elementos necesarios bajo una condición:

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)
element = wait.until(EC.presence_of_element_located((By.ID, "myElem")))

Características clave:

Menor tiempo de inactividad de las pruebas: las pruebas continúan inmediatamente después de que se cumple la condición.
Reducción del porcentaje de falsas alarmas (pruebas inestables) debido a la dinámica de la UI.
Mayor nivel de abstracción (esperas por condiciones complejas, por ejemplo, por cambio de valor de texto o desaparición de elementos).

Preguntas capciosas.

¿Por qué es mejor no usar solo esperas implícitas (implicit waits) en lugar de explícitas?

Las esperas implícitas se aplican a todo el controlador y pueden llevar a retrasos inesperados o conflictos con las esperas explícitas, lo que a menudo conduce a errores de "TimeoutException".

¿Se debe usar Thread.sleep para esperar en pruebas de UI?

El uso de Thread.sleep está extremadamente desaconsejado: conduce a demoras innecesarias e inestabilidad en las pruebas. Es mejor usar esperas explícitas y condiciones.

¿Qué hacer si el elemento aparece con animación?

Esperar la aparición no solo del elemento en sí, sino también de su estado (por ejemplo, visibilidad o capacidad de clic), utilizando condiciones especiales como visibility_of_element_located.

Errores comunes y anti-patrones

Uso de tiempos de espera fijos (sleep) en lugar de condiciones.
Conflicto entre esperas explícitas e implícitas.
Esperar la existencia de un elemento, cuando en realidad se necesita esperar su visibilidad o capacidad para interactuar.

Ejemplo de la vida real

Caso negativo

En el proyecto, la espera por la aparición de un modal se implementó mediante Thread.sleep(3000). A veces la ventana aparecía más rápido, a veces más lento. Los scripts funcionaban lentamente, y al aumentar la carga, a veces las pruebas fallaban.

Pros:

Facilidad de implementación.
Rápidamente implementado sin profundizar en sincronización.

Contras:

Inestabilidad en las pruebas.
Aumento del tiempo de ejecución de las pruebas automatizadas en todos los entornos.
Dificultad para mantener durante las mejoras de la UI.

Caso positivo

Se reestructuró la lógica: todas las acciones con la UI se encapsularon en funciones con esperas explícitas de visibilidad y actividad de elementos, todo se aceleró, y la estabilidad aumentó al 98%.