TESTING AUTOMATIZADO & QA

Playwright vs Selenium: La Revolución del Auto-waiting en Testing E2E

Por qué las esperas automáticas integradas eliminan las pruebas intermitentes (flaky tests) definitivamente.
Patricio 7 agosto, 2026
Automatización Web Playwright QA Selenium Testing E2E

El Fin de los Thread.sleep() y Esperas Explícitas en Pruebas E2E

Avanzando en esta primera semana de agosto de 2026, si hay algo que puedo destacar de la evolución de las pruebas automatizadas es la eliminación definitiva de uno de los mayores dolores de cabeza históricos en Selenium: la gestión manual del DOM. Durante años, mantener suites de prueba implicaba plagar el código de Thread.sleep() o esperas explícitas arbitrarias para evitar que los tests fallaran por problemas de sincronización.

Playwright resolvió este problema de raíz mediante su motor de Auto-waiting (espera automática), el cual evalúa de forma asíncrona una serie de verificaciones de accionabilidad sobre el elemento antes de realizar cualquier interacción como un clic, escritura o selección.

¿Qué verifica Playwright automáticamente antes de hacer un clic?

1. Adjunción al DOM (Attached)
Verifica que el elemento exista efectivamente en la estructura del documento HTML.
2. Visibilidad e Intersección (Visible)
Comprueba que el elemento tenga dimensiones físicas mayores a 0x0 y no esté oculto por estilos como display: none o visibility: hidden.
3. Estabilidad de Animación (Stable)
Asegura que el elemento haya finalizado cualquier transición CSS o animación antes de intentar hacer clic, evitando clics fallidos en coordenadas móviles.
4. Capacidad de Recibir Eventos (Receives Events)
Garantiza que el elemento no esté cubierto u obstruido por overlays, spinners de carga o modales flotantes.
5. Estado Habilitado (Enabled)
Verifica que el botón o control no tenga el atributo disabled activo.

Caso Práctico: Pasarela de Pago durante un CyberDay

Pensemos en el flujo de compra de un e-commerce local al momento de pagar con Webpay o Fpay. Durante eventos de alta demanda como un CyberDay, es habitual que la interfaz muestre un spinner de «Procesando pago…» que bloquea la pantalla con un overlay transparente. En Selenium, si intentabas hacer clic en el botón de confirmación mientras el overlay estaba desapareciendo, el test lanzaba un error de tipo ElementClickInterceptedException.

Con Playwright, el motor espera automáticamente a que el loader se desmonte del DOM y el botón esté 100% habilitado antes de enviar la interacción, sin requerir ninguna línea de espera manual.

Así inspecciona Playwright el estado del botón en el Trace Viewer:

PLAYWRIGHT TRACE
click(«#btn-confirmar-pago»)

Action Log • 320ms

// Evaluando verificaciones de accionabilidad…
[00:00.012] waiting for locator(‘#btn-confirmar-pago’)
[00:00.045] locator resolved to <button id=»btn-confirmar-pago» class=»btn-primary»>Pagar $45.900 CLP</button>
[00:00.080] element is attached to the DOM
[00:00.110] element is visible
[00:00.150] element is obstructed by <div class=»webpay-overlay-loader»> • retrying…
[00:00.280] overlay removed, element receives events
[00:00.310] element is enabled
[00:00.320] attempting click action -> SUCCESS

Paso 4 de 6 • Test: Flujo_Compra_Webpay.spec.ts
Auto-waiting: PASSED

Esta capacidad nativa de esperar automáticamente a que la interfaz vuelva a estar receptiva elimina más del 90% de las pruebas intermitentes (flaky tests), haciendo que las suites de integración en CI/CD sean verdaderamente confiables y acelerando el ciclo de entrega de software.

Volver al Blog