Respuesta.

Historia de la pregunta:

La aparición de aplicaciones de una sola página modernas (SPA) basadas en React, Angular y Vue ha traído nuevos problemas en la automatización de pruebas de interfaz de usuario: carga asíncrona de datos, elementos complejos de la interfaz de usuario, enrutamiento del lado del cliente. Los enfoques clásicos (por ejemplo, basados en selectores o DOM renderizado de forma estática) han dejado de ser confiables para tales aplicaciones.

Problema:

Las pruebas a menudo "fallan" debido a retrasos en la carga, animaciones y cambios asíncronos en los elementos.
Inestabilidad de selectores (ids dinámicos, clases, cambios en la estructura del DOM).
Dificultad para mantener las pruebas después de los cambios en el lado del frontend.

Solución:

Uso de esperas explícitas (explicit waits) para la aparición o cambio de elementos:

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, 20)
my_element = wait.until(EC.visibility_of_element_located((By.ID, 'dynamic_id')))

Trabajar con localizadores más estables (data-testid, atributos únicos).
Organización de la infraestructura de pruebas: simulación de respuestas API, uso de test-helpers especiales.
Inclusión de ganchos especiales o test-id estables en el frontend.

Características clave:

Enfoque en localizadores estables y esperas explícitas
Validación del estado de la UI a través de API o eventos de servicio
Automatización "por capas": unit + integración + E2E

Preguntas trampas.

¿Se puede confiar únicamente en XPATH o selectores CSS en las pruebas para SPA?

No. Los selectores de tipo XPATH/CSS a menudo se rompen con cualquier cambio en el DOM. Es mejor utilizar atributos data-* o test-id resistentes, implantados especialmente en los elementos.

¿Selenium/WebDriverWait resuelve todos los problemas de asincronía?

No. WebDriverWait ayuda a evitar fallos debido a retrasos, pero no garantiza la adecuada carga y estado de una interfaz de usuario compleja. Se requieren verificaciones adicionales, simulación de API y trabajo con estados de UI.

¿Es suficiente verificar solo la presencia de elementos visibles en la página para confirmar la carga correcta de la UI?

No. Se puede erróneamente aceptar una carga "vacía" como exitosa si el elemento se muestra, pero no contiene los datos o el estado esperados. Es necesario validar el contenido y los valores de los campos.

Errores típicos y anti-patrones

Uso de localizadores dinámicos o inestables
Esperas implícitas (sleep en lugar de explicit waits)
Verificar solo la presencia del elemento, sin verificar su valor/contenido
Ausencia de simulación de respuestas/servicios API

Ejemplo de la vida real

Caso negativo

Las pruebas automáticas se ejecutan según un horario, utilizan selectores XPath y retrasos de sleep. Después de actualizar la UI, la mitad de las pruebas fallan debido a la ausencia de elementos o su reubicación con un nuevo id/class.

Ventajas:

Creación rápida de pruebas automatizadas
Estructura simple

Desventajas:

Inestabilidad (pruebas frágiles)
Dificultad para mantener cada lanzamiento

Caso positivo

Se implementan data-testid en la UI, las pruebas utilizan esperas explícitas y ganchos de prueba especiales. Todas las respuestas de red se simulan, las pruebas validan no solo la presencia, sino también el contenido de los elementos.