En la planificacion de sprint ha salido "investigar Playwright para testing". Si es la primera vez que lo escuchas, este post es para ti.

Que es Playwright

Un framework de testing end-to-end para web, creado por Microsoft. Lo hizo el mismo equipo que creo Puppeteer en Google antes de irse a Microsoft.

La idea: controlas un navegador real desde codigo. Abres paginas, haces clicks, rellenas formularios, verificas que todo funciona. Pero a diferencia de Selenium (que lleva desde 2004), Playwright esta diseñado para que los tests no sean fragiles.

El problema que resuelve

Los tests end-to-end tienen mala fama. Son lentos, se rompen sin razon, y nadie quiere mantenerlos.

Playwright ataca las tres causas principales:

Tests fragiles (flaky tests)

El 80% de los tests fragiles vienen de problemas de timing: el test hace click antes de que el boton este visible, o lee un texto antes de que la API responda.

Playwright tiene auto-wait. Antes de cada accion (click, fill, assert), espera automaticamente a que el elemento este visible, habilitado, estable, y listo para recibir eventos. No escribes sleep(2). No escribes waitForElement. Solo dices "click aqui" y Playwright espera lo justo.

Lentitud

Selenium abre una conexion HTTP nueva por cada comando. Click: HTTP request. Leer texto: HTTP request. Cada uno con su latencia.

Playwright usa un WebSocket persistente. Un solo canal abierto todo el rato. Los comandos viajan instantaneos. Resultado: los tests corren en la mitad de tiempo.

Ademas, ejecucion paralela de serie. Cada archivo de tests corre en su propio worker. Sin plugins, sin configuracion, sin pagar nada.

Solo funciona en Chrome

Cypress solo testea Chrome (Firefox con limitaciones). Puppeteer solo Chrome. Selenium soporta todo pero con un setup doloroso.

Playwright controla Chromium (Chrome, Edge), Firefox y WebKit (Safari) con la misma API. Escribes el test una vez, corre en los tres motores.

Como funciona por dentro

Tres capas:

Tu test (JS/TS, Python, Java, C#)
    | WebSocket persistente
    v
Playwright Server (Node.js)
    | protocolo nativo del navegador
    v
Browser (Chromium / Firefox / WebKit)

La clave es el concepto de Browser Context. Cada test recibe su propio contexto, que es como una ventana de incognito: cookies propias, localStorage propio, sesion propia. Crear un contexto tarda milisegundos. Asi los tests no se contaminan entre si y puedes correr muchos en paralelo sobre el mismo navegador.

Browser (una instancia)
  +-- Context 1 (test A) -- aislado
  |     +-- Page 1
  +-- Context 2 (test B) -- aislado
        +-- Page 1

Un test real

import { test, expect } from '@playwright/test';

test('crear un todo y verlo en la lista', async ({ page }) => {
  // Abre la app
  await page.goto('http://localhost:8080');

  // Escribe en el input
  await page.getByPlaceholder('What needs to be done?').fill('Comprar cafe');

  // Click en Add
  await page.getByRole('button', { name: 'Add' }).click();

  // Verifica que aparece en la lista
  await expect(page.getByText('Comprar cafe')).toBeVisible();
});

No hay sleep. No hay waitFor. Playwright espera solo. Si el boton tarda 50ms en estar listo, espera 50ms. Si tarda 2 segundos, espera 2 segundos. Si no aparece nunca, falla con un mensaje claro.

Instalacion

npm init playwright@latest

Te pregunta idioma (TS/JS), carpeta de tests, y si quieres un workflow de GitHub Actions. Descarga los navegadores (~500MB) y listo.

Para correr:

npx playwright test              # todos, headless, paralelo
npx playwright test --headed     # ves el navegador
npx playwright test --ui         # modo interactivo
npx playwright show-report       # informe HTML

Las features que importan

Codegen: graba tests sin escribir codigo

npx playwright codegen http://localhost:8080

Abre un navegador. Tu navegas y haces clicks. Playwright genera el codigo del test en tiempo real. Copias, pegas, ajustas. Ideal para empezar rapido.

Trace Viewer: debug de CI como si estuvieras ahi

Cuando un test falla en CI, Playwright guarda un "trace": capturas del DOM en cada paso, llamadas de red, logs de consola, y un screencast. Lo abres en el navegador y ves exactamente que paso. No mas "funciona en mi maquina".

Interceptar red

await page.route('**/api/todos', route => {
  route.fulfill({
    body: JSON.stringify([{ id: '1', title: 'Mock', completed: false }]),
  });
});

Puedes mockear APIs, bloquear requests, o modificar respuestas al vuelo. Util para testear errores de red, estados vacios, o datos especificos.

Visual regression

await expect(page).toHaveScreenshot('homepage.png');

La primera vez crea la imagen de referencia. Las siguientes veces compara pixel a pixel. Si algo cambia, el test falla y te muestra el diff.

Tests de API sin navegador

test('API devuelve todos', async ({ request }) => {
  const response = await request.get('/todos');
  expect(response.ok()).toBeTruthy();
  const todos = await response.json();
  expect(todos).toHaveLength(3);
});

Puedes mezclar tests de UI y de API en el mismo proyecto.

Comparativa honesta

Cuando NO elegir Playwright

• Necesitas testear en dispositivos moviles reales (usa Appium o BrowserStack)
• Tu equipo de QA no programa (Playwright requiere codigo real, no hay opcion no-code)
• Tienes una suite enorme de Selenium que funciona bien (migrar tiene coste)

Los numeros de 2026

• 13.5 millones de descargas semanales en npm (ha superado a Cypress)
• 94% de retencion (quien lo prueba, se queda)
• 12.400+ empresas usandolo (Amazon, Apple, NVIDIA, Microsoft, IBM)
• Release cada 6-8 semanas

Playwright + Cohete

Para nosotros, Playwright es la pieza que falta para testear el frontend del skeleton. El plan seria:

test('crear todo via UI', async ({ page }) => {
  await page.goto('http://localhost:8080');
  await page.getByPlaceholder('What needs to be done?').fill('Test e2e');
  await page.getByRole('button', { name: 'Add' }).click();
  await expect(page.getByText('Test e2e')).toBeVisible();
});

test('marcar todo como completado', async ({ page }) => {
  // crear via API para tener datos
  await page.request.post('/todos', {
    data: { title: 'Toggle test' }
  });
  await page.goto('http://localhost:8080');
  // click en el checkbox del todo
  // verificar que tiene tachado
});

Levantamos el server async con php src/bootstrap.php, Playwright se conecta, testea la UI contra la API real. Cero mocks. E2E de verdad.

Para quien investiga esto en su sprint

Si tu equipo esta evaluando Playwright, la respuesta corta es: si. Es lo que el mercado esta adoptando. La curva es razonable si el equipo sabe programar, la documentacion es solida, y la comunidad esta activa.

El consejo: empezad con npx playwright codegen grabando tests de los flujos criticos. Luego refinad a mano. Los traces os van a ahorrar horas de debug en CI.

Documentacion oficial: playwright.dev