Pruebas de punta a punta con Playwright

Teoría

Qué es una prueba de punta a punta

Una prueba de punta a punta (end to end, e2e) recorre la aplicación como lo haría una persona: abre el navegador, entra a una URL, hace clic, escribe en un formulario y mira lo que aparece. No simula nada: el front es el que corre de verdad, el back también, y entre los dos hay una red real.

Playwright es la herramienta que usa este curso para escribirlas. Controla un navegador real (por ejemplo, Chromium) desde un programa: es un usuario que no se cansa y que repite el mismo recorrido cada vez. La teoría de Pruebas del front: qué probar y con qué ubica estas pruebas en la punta de la pirámide: pocas, lentas y con el costo más alto. Esta página explica qué prueban y en qué se diferencian de las de Vitest, que son las obligatorias.

En qué se diferencia de las pruebas con Vitest

	Vitest (servicio, componente, integración)	Playwright (punta a punta)
Dónde corre	Un entorno de prueba dentro de Node, sin navegador	Un navegador real, con su motor de renderizado y su red
El back	Simulado: la prueba decide qué responde	El back real, con su base de datos
Qué comprueba	Una pieza, o varias juntas, por dentro	El recorrido completo, por fuera, como lo ve el usuario
Cuando falla	Señala la pieza que se rompió	El error puede estar en el front, en el back, en la red o en los datos
Qué necesita	Nada más que el proyecto	El front y el back corriendo, y datos con los que trabajar
Dónde corre en el curso	`ng test` y el pipeline	La máquina del desarrollador (es opcional)

La diferencia de fondo es qué se da por cierto. Una prueba de Vitest da por cierto que el back responde lo que ella dice; una de Playwright da por cierto muy poco y averigua si las capas realmente se entienden. Una no reemplaza a la otra: miran cosas distintas.

Lo que solo ve una prueba de punta a punta

Las pruebas con el back simulado no hacen ninguna petición real, así que hay errores que no pueden ver:

CORS. Si el back no permite el origen del front, el navegador bloquea la respuesta. Postman no lo ve (no es un navegador) y Vitest tampoco (no hay petición). Con el origen del back cambiado, las pruebas de Vitest siguieron en verde y el recorrido de Playwright falló, porque la aplicación se quedaba en el formulario sin guardar. Es el caso que justifica una prueba de punta a punta.
Que el front y el back de verdad se entienden. Un doble de prueba responde lo que tú escribes; el back real responde lo que responde. Si los dos dejaron de coincidir, solo el recorrido real lo nota.
Lo que el usuario realmente puede hacer. Playwright hace clic como lo haría una persona: si el botón está deshabilitado o tapado, no puede, y la prueba falla (con un botón deshabilitado, el mensaje es element is not enabled).
El historial y las URL de verdad. El botón atrás, recargar una página o escribir una URL en la barra se hacen con el navegador, no con el Router simulado de una prueba.

Lo que hace peor

Las mismas razones que le dan su valor le dan su costo:

Es lenta. Cada prueba abre un navegador y recorre la aplicación completa.
Necesita todo corriendo. Si el back está caído, la prueba falla, y el fallo no dice nada del front.
Los datos importan. El back real guarda lo que la prueba crea, y esos datos siguen ahí en la corrida siguiente. Una prueba que dependa de lo que dejó otra, o de datos que existían, falla de forma intermitente. La salida es crear datos propios y únicos en cada corrida (un nombre con la hora, por ejemplo).
Diagnosticar cuesta más. Cuando falla, el error puede estar en cualquier capa. Por eso se escriben pocas, y solo para los recorridos que más valen.

Cómo es una prueba en Playwright

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

test('al elegir un álbum y asociarlo, se ve en el detalle del artista', async ({ page }) => {
  await page.goto('/artistas/1/add-album');
  await page.getByLabel('Álbum').selectOption({ index: 1 });
  await page.getByRole('button', { name: 'Asociar álbum' }).click();

  await expect(page).toHaveURL('/artistas/1');
});

page es la pestaña del navegador. Cada prueba recibe una nueva, y el almacenamiento del navegador (localStorage, cookies) no se comparte entre pruebas: lo que una guarda, la siguiente no lo ve.
Los localizadores buscan lo que ve el usuario. getByRole('button', { name: 'Asociar álbum' }) busca un botón por su nombre accesible, getByLabel('Álbum') un campo por su etiqueta y getByText un texto. Son más estables que un selector CSS, porque no cambian si se reordena el HTML, y obligan a que la aplicación sea accesible: si un lector de pantalla no encuentra el botón, tampoco lo encuentra la prueba.
Un localizador debe señalar un solo elemento. Si coincide con varios, Playwright falla con strict mode violation en vez de elegir uno: getByRole('link', { name: 'artista' }) coincide con “Artistas” y con “Nuevo artista” en el menú de la aplicación del curso.
Las aserciones esperan solas. await expect(page).toHaveURL(...) reintenta hasta que se cumple o se acaba el tiempo (cinco segundos por defecto), así que no hace falta escribir pausas. Si la espera se acaba, el mensaje dice qué esperaba y qué recibió.

Qué recorridos probar

Como son caras, las pruebas de punta a punta no repiten lo que ya cubren las de Vitest. Se escogen los recorridos que cruzan las capas:

Un camino feliz por cada funcionalidad importante: crear un recurso, abrir su detalle, asociarlo con otro y ver el resultado.
Solo los casos de error que dependen de la integración real, como una respuesta bloqueada por CORS.

Los casos de error del back (400, 404) y las vistas sin datos se prueban abajo, con el back simulado: allí son rápidos y se pueden provocar a voluntad.

Por qué es opcional en este curso

Vitest corre en el pipeline en cada PR, y una prueba que falla deja el build en rojo. Las pruebas de Playwright no: necesitan el front y el back corriendo, y el pipeline no los levanta. Se ejecutan en la máquina del desarrollador, antes de entregar, para recorrer la aplicación completa una vez. Si las haces, el tutorial de una prueba de punta a punta te muestra cómo.

Autoevaluación

1. ¿Qué diferencia a una prueba de Playwright de una de Vitest con el back simulado?

Playwright prueba el back y Vitest prueba el frontPlaywright usa un navegador real y el back real; Vitest responde las peticiones desde la pruebaPlaywright es más rápida porque no necesita preparar nada

2. El back cambia su CORS y el front deja de poder guardar. Las pruebas de Vitest siguen en verde. ¿Por qué?

Porque las pruebas de Vitest tienen un errorPorque no hacen peticiones reales: el navegador nunca aplica la política de CORSPorque CORS solo falla con el back en producción

3. Una prueba de punta a punta crea un artista llamado 'Prueba' y funciona. Al correrla otra vez falla. ¿Cuál es la causa más probable?

Playwright guarda estado entre corridas y se corrompeEl back conservó el artista de la corrida anterior y la prueba depende de que no existaEl navegador se quedó abierto de la corrida anterior

4. ¿Por qué se prefiere getByRole('button', { name: 'Asociar álbum' }) a un selector CSS como '.btn-primary'?

Porque es más corto de escribirPorque busca lo que ve el usuario, no cambia si se reordena el HTML y obliga a que el botón sea accesiblePorque los selectores CSS no funcionan en Playwright

5. ¿Por qué conviene escribir pocas pruebas de punta a punta y dejar los casos de error del back para Vitest?

Porque Playwright no puede simular un error del backPorque son lentas y su fallo es difícil de ubicar, y con el back simulado los errores se provocan rápido y a voluntadPorque Vitest es la única herramienta permitida en el curso