Logo de JSCamp

Qué es un Test E2E y cómo montarlo con Playwright

En esta clase subimos de nivel: ya tenemos validaciones y tests, pero aún no hemos tocado “los buenos”. Los tests E2E (end-to-end) son los que te aseguran que tu app funciona de punta a punta, como lo haría un usuario real.

Antes de E2E: validaciones donde toca

Algo clave: las validaciones se hacen en frontend y en backend.

  • En frontend son recomendables porque mejoran la experiencia - el usuario sabe antes qué está mal sin esperar al servidor.
  • En backend son obligatorias - es donde garantizas que lo que entra es válido antes de guardarlo o procesarlo.

Y si solo pudieras validar en un sitio: en backend, siempre.

¿Qué es un test E2E?

Un test E2E simula el comportamiento de un usuario para comprobar el flujo completo:

  • que una página carga,
  • que al hacer clic ocurre lo esperado,
  • que una API responde,
  • que se renderiza el contenido correcto,
  • etc.

Es decir, prueba el sistema “de extremo a extremo”.

Herramienta: Playwright

Para esto vamos a usar Playwright, una herramienta open source de Microsoft para automatizar navegadores.

Lo interesante es que te permite:

  • ejecutar tests E2E,
  • controlar un navegador,
  • incluso hacer scraping si lo necesitas.

Y aunque existe en varios lenguajes, en Node.js es donde suele brillar más.

Inicializando un proyecto de testing con Playwright

Playwright te lo deja mascado con un init. Estructura típica que creamos en el repo:

mkdir 05-testing
cd 05-testing
npm init playwright@latest

En el asistente, una configuración típica:

  • JavaScript
  • tests dentro de tests/
  • (opcional) GitHub Actions workflow
  • instalar navegadores de Playwright

Tras esto, te genera un ejemplo tipo tests/example.spec.js.

Entendiendo el test de ejemplo

El ejemplo suele importar desde @playwright/test y probar cosas como:

  • que la página tiene un título,
  • que existe un link tipo “Get started”,
  • que al hacer clic aparece un heading concreto (por ejemplo “Installation”).

Conceptualmente se ve así:

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

test('tiene un título', async ({ page }) => {
  await page.goto('https://playwright.dev/')
  await expect(page).toHaveTitle(/Playwright/)
})

test('navega al get started', async ({ page }) => {
  await page.goto('https://playwright.dev/')
  await page.getByRole('link', { name: 'Get started' }).click()
  await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible()
})

(Este no tiene por qué ser idéntico a tu repo, pero la idea es esa.)

Ejecutando los tests

Para correrlos:

npx playwright test

Y aquí viene lo típico: “vale, se ejecutó, pero no vi nada”. Normal: por defecto corre en modo headless (sin ventana, más rápido).

Verlos paso a paso con la UI

Playwright tiene un modo UI para ver la ejecución y cada paso (navigate, click, expect, etc.):

npx playwright test --ui

Esto te abre una interfaz donde puedes reproducir el test y ver exactamente qué hizo y dónde hizo clic.

¿Por qué salen “más tests” de los que escribiste?

Porque por defecto Playwright puede ejecutar lo mismo en varios navegadores.

Ejemplo del vídeo:

  • 2 tests
  • 3 navegadores (Chromium/Chrome, Firefox, WebKit/Safari)
  • total: 6 ejecuciones

Así que no es magia, es multiplicación (la buena, no la de inventarse coverage).

Ver el navegador en pantalla: headed

Si quieres ver las ventanas del navegador mientras corre (modo visual):

npx playwright test --headed
  • Headless = sin ventana (rápido).
  • Headed = con ventana (útil para depurar).

Ventajas reales de los E2E

  • Confianza: validas flujos completos, no piezas sueltas.
  • Simulas al usuario: clicks, navegación, expectativas reales.
  • Detectas integraciones rotas: frontend + backend + routing + render.

Lo que hemos aprendido

  • Qué es un test E2E y por qué es el más valioso (punto a punto).
  • Por qué validar en backend es obligatorio y en frontend recomendable.
  • Cómo inicializar Playwright con npm init playwright@latest.
  • Cómo ejecutar tests con npx playwright test.
  • Cómo depurar con --ui y entender headless vs headed.

En la siguiente clase ya podemos empezar a escribir E2E para nuestra propia app, no para la web de Playwright (aunque oye, está bien saber que al menos ellos la tienen testeada).