Playwright es el framework de testing end-to-end desarrollado por Microsoft que permite automatizar pruebas en aplicaciones web con soporte nativo para Chromium, Firefox y WebKit. La versión 1.50 consolida capacidades como el UI mode con time travel, test.step para etiquetar pasos en el Trace Viewer, component testing estable para React, Vue y Svelte, snapshots visuales mejorados y una integración más fina con TypeScript que afina los tipos de las fixtures y de los matchers. El ecosistema se amplía con @playwright/mcp, el servidor Playwright MCP que expone el navegador como herramienta a agentes de IA para automatizar exploración, scraping y generación de tests.
Playwright destaca por su mecanismo de auto-waiting basado en locators, su capacidad de ejecutar tests en paralelo con aislamiento total entre browser contexts y herramientas de diagnóstico como Trace Viewer, grabación de vídeo y reporters HTML que facilitan el post-mortem de cada fallo. A diferencia de otros frameworks, Playwright ofrece una API unificada que funciona de forma idéntica en los tres motores de navegador, permite testing de APIs REST sin necesidad de navegador mediante la fixture request, soporta interceptación y mock de peticiones de red e incluye regresión visual con toHaveScreenshot.
Este itinerario recorre desde la instalación y configuración inicial hasta la integración de Playwright en pipelines de CI/CD con ejecución paralela y sharding. Aprenderás a escribir tests robustos utilizando locators semánticos, aplicar Page Object Model y fixtures personalizadas, realizar testing de APIs, configurar visual regressión y desplegar tus suites en GitHub Actions y Docker para una ejecución escalable y automatizada.
Arquitectura de Playwright
El cliente de test arranca en Node y se conecta al navegador mediante WebSocket usando protocolos nativos: CDP para Chromium y protocolos específicos para Firefox y WebKit. El resultado es latencia mínima frente a los enfoques basados en WebDriver.
flowchart LR
TestRunner[Test Runner @playwright/test] --> Library[Playwright Library Node]
Library -->|WebSocket CDP| Chromium[Chromium]
Library -->|WebSocket nativo| Firefox[Firefox]
Library -->|WebSocket nativo| WebKit[WebKit]
Chromium --> CtxC[BrowserContext N]
Firefox --> CtxF[BrowserContext N]
WebKit --> CtxW[BrowserContext N]
CtxC --> PageC[Page]
CtxF --> PageF[Page]
CtxW --> PageW[Page]
Auto-waiting basado en locators
Los locators son handles reactivos: cada acción espera automáticamente a que el elemento sea actionable antes de interactuar. Este flujo reemplaza las esperas manuales típicas de Selenium.
flowchart TD
A[locator.click] --> B{Elemento adjunto al DOM?}
B -->|No| W1[Esperar hasta timeout]
B -->|Si| C{Visible?}
C -->|No| W2[Esperar hasta timeout]
C -->|Si| D{Estable sin animación?}
D -->|No| W3[Esperar hasta timeout]
D -->|Si| E{Habilitado y recibe eventos?}
E -->|No| W4[Esperar hasta timeout]
E -->|Si| F[Ejecutar click]
W1 --> B
W2 --> C
W3 --> D
W4 --> E
Flujo del Trace Viewer
El Trace Viewer permite abrir un archivo trace.zip y revisar cada paso del test, el DOM, la red, la consola y los snapshots anteriores y posteriores a cada acción.
flowchart LR
Run[npx playwright test] -->|trace: on-first-retry| Zip[trace.zip]
Zip --> Show[npx playwright show-trace]
Show --> Timeline[Timeline de acciones]
Show --> Steps[test.step y locators]
Show --> Network[Peticiones de red]
Show --> Console[Consola del navegador]
Show --> Dom[Snapshots DOM antes y después]
Test isolation y workers en paralelo
fullyParallel: true distribuye los tests entre workers, cada uno con su propio browser context aislado.
flowchart TD
Suite[Suite de tests] --> Pool{Pool de workers}
Pool --> W1[Worker 1]
Pool --> W2[Worker 2]
Pool --> W3[Worker 3]
W1 --> Ctx1[BrowserContext aislado]
W2 --> Ctx2[BrowserContext aislado]
W3 --> Ctx3[BrowserContext aislado]
Ctx1 --> T1[tests/a.spec.ts]
Ctx2 --> T2[tests/b.spec.ts]
Ctx3 --> T3[tests/c.spec.ts]
Component testing
Playwright Component Testing monta componentes aislados y los renderiza en el navegador real, sin jsdom ni mocks de DOM.
flowchart LR
Test[Test component] --> Mount[mount Componente]
Mount --> Vite[Playwright CT runner]
Vite --> Browser[Navegador real Chromium]
Browser --> Assert[expect locator auto-waiting]
Assert --> Report[HTML reporter]
Sharding en CI
El sharding divide la suite entre varias máquinas y consolida los resultados con npx playwright merge-reports.
flowchart LR
CI[GitHub Actions] --> M{Matrix shard}
M --> S1[shard 1/3]
M --> S2[shard 2/3]
M --> S3[shard 3/3]
S1 --> Blob1[blob-report 1]
S2 --> Blob2[blob-report 2]
S3 --> Blob3[blob-report 3]
Blob1 --> Merge[merge-reports]
Blob2 --> Merge
Blob3 --> Merge
Merge --> HTML[HTML único]
Merge --> Allure[Allure report]
Qué incluye este itinerario
- Fundamentos: qué es Playwright, arquitectura, comparativa con Cypress y Selenium, browser contexts y pages.
- Instalación y configuración: setup con npm, playwright.config.ts, extensión de VS Code y primer test.
- Selectores y locators: getByRole, getByText, getByTestId, CSS/XPath, filtrado y encadenamiento de locators.
- Interacciones: click, fill, teclado, ratón, subida de archivos, diálogos, auto-waiting y frames.
- Assertions: web-first assertions con auto-retry, assertions de página, soft assertions y custom matchers.
- Patrones avanzados: Page Object Model, fixtures, hooks, parametrización y test isolation con storage state.
- API testing: APIRequestContext, testing de REST APIs, mock de respuestas e intercepción de red con HAR files.
- Visual testing: comparación de screenshots, Trace Viewer, grabación de vídeo y testing de accesibilidad.
- CI/CD: ejecución paralela, sharding, reporters, GitHub Actions y Docker.
- Retos de código: test E2E de login, fixtures con storageState, API REST con
requesty regresión visual contoHaveScreenshot. - Proyecto integrador: suite completa con POM, fixtures, API, visual regressión, Trace Viewer y GitHub Actions con sharding y reporters Allure.
Público objetivo
- Desarrolladores frontend y full-stack que quieren automatizar las pruebas de sus aplicaciones web con un framework moderno y fiable.
- Ingenieros QA y testers que buscan migrar de Selenium o Cypress a una herramienta con mejor rendimiento y capacidades multi-navegador.
- Equipos de desarrollo que necesitan integrar testing E2E en sus pipelines de CI/CD de forma escalable.
- Estudiantes de informática que desean adquirir competencias en automatización de pruebas y calidad de software.
- DevOps y SRE que necesitan configurar infraestructura de testing automatizado en entornos de integración continua.
Prerrequisitos: conocimientos de JavaScript o TypeScript y familiaridad con el desarrollo de aplicaciones web (HTML, CSS, HTTP). No se requiere experiencia previa con frameworks de testing E2E, aunque es recomendable haber escrito tests unitarios anteriormente.