Tu agente te entrega una landing “lista para publicar”. La pantalla se ve bien, pero el botón principal lleva a una ruta que no existe y el formulario acepta un correo inválido. Son fallos pequeños que una captura bonita no revela. Antes de compartir el enlace, dedica diez minutos a comprobar el recorrido que hará un usuario real.

Playwright Test abre la app en un navegador y verifica lo que el usuario ve. Su guía oficial de instalación incluye el comando para añadirlo a un proyecto y sus ejemplos de pruebas usan acciones y aserciones que esperan a que la interfaz esté lista. Aquí tienes una prueba inicial para una app creada con Cursor, Lovable, Replit o cualquier otro generador que te dé acceso al proyecto. Es una plantilla para adaptar a tu app: no afirmo que se haya ejecutado contra la tuya.

Elige un recorrido, no veinte botones

Escoge el camino que sostiene la promesa de la página: abrir la landing, encontrar el CTA, llegar a contacto y comprobar que el campo de correo rechaza una entrada claramente inválida. Si tu producto vende una suscripción, sustituye contacto por el primer paso del checkout en un entorno de pruebas. Evita enviar formularios reales o efectuar pagos desde una prueba de humo.

Instala Playwright en la raíz del proyecto con npm init playwright@latest. El asistente pregunta por TypeScript o JavaScript, carpeta de pruebas y navegadores. Arranca tu app con su comando habitual en otra terminal. Si usa el puerto 3000, la plantilla funciona con su URL por defecto; si no, define BASE_URL.

Prueba copiable

Guarda este archivo como tests/recorrido-principal.spec.ts. Cambia “Solicitar demo”, “/contacto” y “Correo electrónico” por los nombres y la ruta reales de tu app. Los selectores por rol y etiqueta son más parecidos a la forma en que una persona encuentra controles que un selector CSS generado al azar.

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

const baseURL = process.env.BASE_URL ?? 'http://localhost:3000';

test('el usuario llega al formulario y el correo se valida', async ({ page }) => {
  const response = await page.goto(baseURL);
  expect(response?.ok()).toBeTruthy();

  await expect(page.getByRole('heading', { level: 1 })).toBeVisible();
  const cta = page.getByRole('link', { name: 'Solicitar demo' });
  await expect(cta).toBeVisible();
  await cta.click();

  await expect(page).toHaveURL(/\/contacto\/?$/);
  const email = page.getByLabel('Correo electrónico');
  await expect(email).toBeVisible();
  await email.fill('correo-invalido');
  const esValido = await email.evaluate(
    (element) => (element as HTMLInputElement).checkValidity()
  );
  expect(esValido).toBe(false);
});

Ejecuta npx playwright test tests/recorrido-principal.spec.ts. Si tu app usa otro puerto, por ejemplo BASE_URL=http://localhost:5173 npx playwright test tests/recorrido-principal.spec.ts. En Windows la forma de definir la variable cambia; también puedes fijar la URL en el archivo para una prueba local. El test no envía el formulario: se detiene antes de crear una solicitud real.

Qué hacer cuando falle

Si falla al cargar, comprueba que el servidor esté corriendo y que BASE_URL corresponda a la app. Si no encuentra el CTA, inspecciona el texto visible y el rol del control: quizá sea un botón, no un enlace. Si navega a otra ruta, corrige la expectativa o el enlace real; no edites el test hasta que pase sin entender el cambio. Si el correo inválido resulta válido, revisa si el campo es de tipo email o si la app usa una validación propia. En ese último caso, prueba el mensaje de error que ve el usuario.

Después de corregir, ejecuta de nuevo la misma prueba y abre manualmente la página en móvil. Playwright admite Chromium, WebKit y Firefox, pero una pasada en un navegador no demuestra que toda la app funciona ni que es segura. Tampoco verifica datos, pagos o permisos de otros usuarios. Para un lanzamiento real, añade pruebas específicas para esos riesgos. La documentación de aserciones explica cómo comprobar texto, URL, visibilidad y otros estados sin introducir esperas arbitrarias.

Cuándo pedir ayuda a la IA

Entrega al agente el fallo exacto y una regla: “repara la causa, conserva la intención del test y muéstrame el diff”. No aceptes una solución que borre la aserción fallida. El valor está en convertir una promesa de producto en una comprobación repetible, no en obtener una línea verde a cualquier precio.