Los tests end-to-end tienen fama de ser lentos, inestables y costosos de mantener. Playwright, el framework de automatización de browsers de Microsoft, ataca directamente las causas raíz de esos problemas. El soporte multi-browser, la espera automática y los contextos de browser aislados producen tests más rápidos de escribir y con menos probabilidad de fallar por razones ajenas al código bajo prueba.
Aquí se explica por qué vale la pena adoptar Playwright y cómo comenzar.
¿Por Qué Usar Playwright para Pruebas Web?
Soporte Multi-Browser
Playwright soporta Chromium, Firefox y WebKit desde una única API. Un solo archivo de test cubre los tres browsers sin duplicar lógica. Esto importa porque las diferencias de renderizado entre browsers siguen causando bugs reales para los usuarios, y encontrarlos en CI es mucho más barato que encontrarlos en producción.
Aislamiento Total con Browser Contexts
Los browser contexts proporcionan múltiples sesiones aisladas dentro de una única instancia de browser. Los tests no comparten cookies, local storage ni caché. Esto elimina una fuente común de interdependencia entre tests, donde los efectos secundarios de un test hacen que otro falle de manera impredecible.
Auto-Wait y Tests Resilientes
Playwright espera a que los elementos sean accionables antes de interactuar con ellos. Verifica que un elemento sea visible, esté habilitado y no esté obstruido antes de hacer clic o escribir. Esto elimina la necesidad de llamadas explícitas a sleep o bucles de reintento que hacen que los tests sean lentos y frágiles.
Soporte de Lenguajes
Playwright tiene soporte de primera clase para JavaScript, TypeScript, Python, Java y .NET. La mayoría de los equipos Node.js usan TypeScript, lo que proporciona verificaciones estáticas en strings de selector y tipos de aserción.
Capacidades Adicionales
Playwright puede interceptar y modificar solicitudes de red, simular geolocalización, controlar permisos del browser, emular viewports móviles, capturar screenshots en caso de fallo y generar archivos de trace para depuración. Estas no son características de nicho; aparecen regularmente en suites de tests reales.
Comenzando con Playwright
Requisitos Previos
- Node.js instalado. Descárgalo desde nodejs.org.
- Familiaridad con JavaScript o TypeScript.
- Un editor de código, preferiblemente Visual Studio Code.
Instalación
npm install --save-dev playwright
Esto instala Playwright y descarga los binarios de los browsers para Chromium, Firefox y WebKit.
Configuración del Proyecto
mkdir playwright-tests
cd playwright-tests
npm init -y
Configuración de TypeScript (Opcional)
npm install --save-dev typescript ts-node
Crea un archivo tsconfig.json:
{
"compilerOptions": {
"target": "ESNext",
"module": "commonjs",
"strict": true,
"esModuleInterop": true,
"moduleResolution": "node",
"resolveJsonModule": true,
"outDir": "dist"
}
}
Creando Tu Primer Test
Escribiendo el Test
Crea un archivo llamado example.spec.js:
const { chromium } = require('playwright');
(async () => {
// Iniciar browser
const browser = await chromium.launch({ headless: false });
const context = await browser.newContext();
// Abrir nueva página
const page = await context.newPage();
// Navegar a la URL
await page.goto('https://www.example.com');
// Obtener título de la página
const title = await page.title();
console.log(`Page title: ${title}`);
// Cerrar browser
await browser.close();
})();
Ejecutando el Test
node example.spec.js
Establecer headless: false abre una ventana de browser visible para que puedas observar la ejecución del test. Útil para depuración; establécelo en true en CI.
Añadiendo Aserciones con Playwright Test
Instala el test runner integrado:
npm install --save-dev @playwright/test
Reescribe el test con aserciones apropiadas:
// example.spec.js
const { test, expect } = require('@playwright/test');
test('Verify page title', async ({ page }) => {
await page.goto('https://www.example.com');
await expect(page).toHaveTitle('Example Domain');
});
Actualiza package.json:
"scripts": {
"test": "playwright test"
}
Luego ejecuta:
npm run test
Funcionalidades Avanzadas
Pruebas Cross-Browser
const { test, expect } = require('@playwright/test');
test.describe.configure({ mode: 'parallel' });
for (const browserType of ['chromium', 'firefox', 'webkit']) {
test(`Verify page title in ${browserType}`, async ({ browser }) => {
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://www.example.com');
await expect(page).toHaveTitle('Example Domain');
await context.close();
});
}
Screenshots y Tracing
test('Verify page title with screenshot', async ({ page }, testInfo) => {
try {
await page.goto('https://www.example.com');
await expect(page).toHaveTitle('Example Domain');
} catch (error) {
await page.screenshot({ path: `screenshots/${testInfo.title}.png` });
throw error;
}
});
Pruebas de API
Playwright maneja solicitudes de API junto con interacciones del browser, lo que es útil para configurar el estado del test sin pasar por la UI:
test('API test', async ({ request }) => {
const response = await request.get('https://api.example.com/data');
expect(response.status()).toBe(200);
const data = await response.json();
expect(data).toHaveProperty('key');
});
Buenas Prácticas
Usa el Page Object Model para mantener los selectores y la lógica específica de cada página fuera de los archivos de test. Los tests deben leerse como especificaciones, no como scripts de traversal del DOM. Usa los hooks beforeAll, beforeEach, afterAll y afterEach para configurar y desmontar el estado. Ejecuta los tests en paralelo para mantener la suite rápida. Gestiona la configuración de entorno mediante archivos de configuración en lugar de URLs hardcodeadas.
Integra Playwright en tu pipeline de CI desde el principio. Los tests que solo se ejecutan localmente no son realmente tests.
Integración con CI
GitHub Actions
Crea .github/workflows/playwright.yml:
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: npm install
- name: Run Playwright tests
run: npm run test
Conclusión
La espera automática de Playwright por sí sola elimina la mayor parte de la fragilidad que hace que los tests E2E sean difíciles de mantener. El soporte cross-browser y las capacidades de intercepción de red lo hacen genuinamente útil para el tipo de bugs que se escapan de los tests unitarios. Si tu proyecto no tiene cobertura E2E, Playwright es el framework con el que empezar. Si tu proyecto tiene tests Selenium o Cypress existentes, Playwright vale la pena evaluarlo para nuevas suites, especialmente donde la cobertura cross-browser o la ejecución paralela han sido un cuello de botella.