Volver al blog

· por Omar Demaría

Cómo automatizar tu primer test con Playwright

Guía paso a paso para empezar con Playwright en menos de 30 minutos. Setup, primer test y CI/CD básico.

  • automatización
  • playwright
  • tutorial

Playwright es uno de los frameworks de automatización más adoptados de los últimos años, y por buenas razones: API simple, multi-navegador real, excelente debugging y velocidad. Si nunca lo has usado, en los próximos 30 minutos vas a tener tu primer test corriendo de forma confiable.

Por qué Playwright

A diferencia de Selenium, Playwright fue construido desde cero para apps modernas: maneja autenticación, redes, descargas y elementos dinámicos sin los workarounds que probablemente conozcas. Y a diferencia de Cypress, corre en Chromium, Firefox y WebKit reales — no en una versión modificada del navegador.

Para equipos pequeños que arrancan QA desde cero, mi recomendación por defecto es Playwright.

Setup en 5 minutos

mkdir mi-suite-qa && cd mi-suite-qa
pnpm init
pnpm dlx playwright install
pnpm add -D @playwright/test

El comando playwright install descarga las versiones de los navegadores que Playwright controla — esto es lo que te asegura builds consistentes en local y en CI.

Tu primer test

Crea tests/login.spec.ts:

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

test("usuario puede iniciar sesión", async ({ page }) => {
  await page.goto("https://miapp.cl/login");
  await page.getByLabel("Email").fill("[email protected]");
  await page.getByLabel("Contraseña").fill("password123");
  await page.getByRole("button", { name: "Iniciar sesión" }).click();
  await expect(page).toHaveURL(/\/dashboard/);
  await expect(page.getByText("Bienvenido")).toBeVisible();
});

Lo importante acá: estamos usando role-based selectors (getByLabel, getByRole). Estos son resilientes a cambios de markup y, además, son accesibles por diseño — si el test falla, probablemente la accesibilidad también.

Corriendo el test

pnpm playwright test

Si pasa: ¡listo! Ya tienes tu primer test automatizado. Si falla, ejecuta con --debug para abrir el inspector visual y ver exactamente dónde se cae.

Próximos pasos

  1. Configurar GitHub Actions para correr los tests en cada PR
  2. Agregar fixtures para reutilizar setup (login, datos de prueba)
  3. Activar trace viewer para debugging post-mortem en CI

En un próximo artículo cubriré la configuración de CI/CD para que estos tests corran automáticamente en cada deploy.