Automatización de pruebas con Playwright para una cobertura E2E y multinavegador fiable

Playwright admite de forma nativa todos los navegadores principales (Chromium, Firefox, WebKit) desde una sola API, ejecuta las pruebas en paralelo de serie e incluye pruebas de componentes y de API sin herramientas adicionales. Cypress ofrece una gran experiencia de desarrollo en flujos de un solo navegador, pero históricamente ha ido por detrás en el soporte de Firefox y WebKit. Selenium es maduro y admite muchos lenguajes, pero requiere más código repetitivo y una infraestructura de grid externa para paralelizar. En la mayoría de los proyectos nuevos de 2024 en adelante, Playwright ofrece la mejor combinación de cobertura de navegadores, velocidad y mantenibilidad.

La inestabilidad casi siempre se debe a suposiciones de temporización: llamadas explícitas a `sleep`, sondeos del estado del DOM o condiciones de carrera entre las respuestas de red y las actualizaciones de la interfaz. Sustituimos cada espera basada en tiempo por el motor de auto-wait de Playwright y aserciones web-first (`toBeVisible`, `toHaveText`, `toHaveURL`), que reintentan hasta que se cumple la condición o expira el tiempo de espera. En las pruebas que interactúan con APIs o trabajos en segundo plano usamos la interceptación de solicitudes o helpers de sondeo en lugar de retardos fijos. Además, ejecutamos la suite diez veces seguidas en el CI antes del traspaso para sacar a la luz los fallos intermitentes.

Playwright incluye tres familias de motores de navegador: Chromium (que cubre Chrome y Edge), Firefox y WebKit (que cubre Safari en macOS e iOS). Las tres se instalan como paquetes versionados de npm/pip junto a la biblioteca de Playwright, así que no hay que mantener un grid de navegadores externo. Configuramos un proyecto de Playwright por motor de navegador para que un mismo archivo de pruebas se ejecute contra los tres en el CI. Para los equipos con requisitos concretos de navegadores móviles, Playwright también permite emular viewports de dispositivos, eventos táctiles y geolocalización.

Playwright se integra de forma nativa con GitHub Actions, GitLab CI, Azure Pipelines, Jenkins y la mayoría de los demás sistemas de CI. Configuramos el pipeline para instalar los navegadores con `playwright install --with-deps`, ejecutar las pruebas con `--reporter=html,junit` para obtener una salida legible tanto por personas como por máquinas y publicar el informe HTML como artefacto del CI enlazado desde la pull request. En las suites grandes activamos el sharding entre varios workers con la sintaxis `--shard=1/4` y después fusionamos los informes de los shards en un paso posterior, lo que reduce una suite de 20 minutos a menos de seis minutos con cuatro workers.

La prueba de regresión visual captura una línea base en forma de captura de pantalla de una página o un componente y la compara píxel a píxel con ejecuciones futuras, señalando desplazamientos del layout, cambios de color o elementos ausentes. La aserción `toHaveScreenshot` de Playwright lo gestiona de forma nativa: guarda un PNG de referencia en la primera ejecución y calcula las diferencias con él en las siguientes, con un umbral de diferencia de píxeles configurable. Configuramos enmascaramiento por región para marcas de tiempo, avatares y otro contenido dinámico, fijamos umbrales adecuados para cada tipo de componente e integramos la aprobación de las actualizaciones de las líneas base en el proceso de revisión de PR, para que los cambios visuales sean deliberados y no accidentales.

Las pruebas E2E lanzan un navegador completo contra una aplicación en ejecución: ejercitan llamadas de red reales, el estado de la base de datos y todos los puntos de integración, lo que las convierte en el tipo de prueba de mayor fidelidad pero también el más lento. Las pruebas de componentes de Playwright montan un único componente de React, Vue o Svelte en un contexto de navegador mínimo servido por Vite o un bundler similar, sin backend. Las pruebas de componentes son más rápidas, más aisladas y más fáciles de depurar que las E2E, por lo que son ideales para la lógica de la interfaz, los casos límite de renderizado y los estados de interacción. Solemos recomendar un enfoque por capas: pruebas de componentes para las unidades de interfaz individuales, pruebas de API para la validación de contratos y pruebas E2E solo para los itinerarios de usuario críticos.

Sí. El paquete @axe-core/playwright inyecta el motor de accesibilidad axe-core en una página de Playwright y devuelve un informe estructurado de infracciones de WCAG 2.1. Añadimos una aserción `expect(accessibilityScanResults.violations).toEqual([])` a las pruebas de páginas y componentes pertinentes para que las regresiones de accesibilidad hagan fallar el control del CI junto con las regresiones funcionales. Cada infracción del informe incluye el criterio de éxito de WCAG, el elemento HTML afectado y una descripción de cómo corregirla, lo que da a los desarrolladores resultados específicos y accionables. Esto ofrece una cobertura de accesibilidad continua sin depender de auditorías manuales periódicas.