Prueba end-to-end (E2E)

Una prueba end-to-end (E2E, de extremo a extremo) ejercita el sistema como lo hace un usuario, con todas las capas reales: navegador, front end, servicios de back end, base de datos, colas y, cuando es viable, integraciones de terceros. Responde a la pregunta que los niveles inferiores no pueden responder: ¿funciona todo junto en un recorrido real? Las pruebas E2E están en la cima de la pirámide de pruebas porque dan la confianza más realista al coste más alto.

Ejemplo (Playwright)

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

test('guest can buy a product', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('searchbox', { name: 'Search' }).fill('desk lamp');
  await page.keyboard.press('Enter');
  await page.getByRole('link', { name: 'Desk Lamp' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await page.getByLabel('Email').fill('guest@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();
});

Una sola prueba atraviesa los servicios de búsqueda, catálogo, carrito, checkout y pedidos. Si el servicio del carrito serializa mal los precios, esta prueba lo detecta aunque pasen las pruebas unitarias de todos los servicios.

Por qué conviene tener pocas

• Lentas. Segundos o minutos cada una, frente a milisegundos de las pruebas unitarias.
• Propensas a ser flaky. Más piezas móviles significan más problemas de tiempos, datos compartidos e inestabilidad del entorno.
• Diagnóstico pobre. “El checkout falló” puede deberse a cualquiera de una docena de servicios.
• Caras de mantener. Los cambios en la UI repercuten en muchas pruebas.

Por eso conviene reservar las pruebas E2E para los recorridos de negocio críticos, como el registro, la compra y los flujos principales, y cubrir las variaciones (cada regla de validación, cada tipo de descuento) en los niveles unitario y de API.

Cómo hacerlas fiables

• Usa esperas basadas en condiciones, como el auto-waiting y las web-first assertions de Playwright o WebDriverWait en Selenium; nunca pausas fijas.
• Crea los datos de prueba a través de APIs en el setup en lugar de hacer clic por la UI, y da a cada prueba sus propios datos.
• Usa locators estables: roles, etiquetas y test IDs en lugar de XPath que dependa del layout.
• Estructura el código con page objects o algo similar para que un cambio en la UI se corrija en un solo lugar.

“End-to-end” y “prueba de sistema” se solapan: las pruebas de sistema son un nivel de prueba, mientras que E2E describe el estilo de prueba que atraviesa todas las capas.