Cómo automatizar pruebas E2E: guía completa

Una prueba end-to-end recorre tu aplicación como lo haría una persona: abre el navegador, hace clic, escribe, espera respuestas y comprueba que el resultado sea el correcto. No prueba una función aislada: prueba que el conjunto funcione.

Automatizarlas significa que ese recorrido lo haga una máquina, todas las veces que haga falta, sin que nadie tenga que acordarse.

Esta guía cubre el camino completo: qué automatizar, con qué, dónde ejecutarlo y cómo saber si el verde que te devuelve significa algo.

Antes de empezar: qué automatizar

El error más común es querer cubrirlo todo. Una suite de ochenta tests que nadie mantiene termina desactivada en tres meses.

Empieza por los flujos donde perderías dinero o clientes si se rompen. En un ecommerce son tres o cuatro: registrarse, buscar un producto, pagar, y ver el pedido. En un SaaS: registro, el flujo principal del producto, y el cobro.

Un criterio que funciona: si el flujo se rompiera un viernes a las seis de la tarde, ¿alguien llamaría por teléfono? Si la respuesta es sí, va a la suite.

Lo que no conviene automatizar en E2E:

• Validaciones de un solo campo. Eso es un test unitario y corre en milisegundos.
• Pantallas que cambian cada semana. Vas a pasar más tiempo arreglando el test que probando.
• Reglas de negocio internas sin interfaz. Se prueban por debajo, no por el navegador.

Elegir la herramienta

Hoy la conversación se reduce a tres nombres, y los comparamos en detalle en Playwright vs Cypress vs Selenium.

El resumen: Playwright es la elección por defecto en 2026 para un proyecto nuevo. Es gratuito, soporta los tres motores de navegador, trae espera automática por condición y su trace te deja reconstruir qué pasó en una corrida fallida.

Cypress sigue siendo cómodo si tu equipo ya lo domina. Selenium solo tiene sentido si necesitas navegadores o lenguajes que los otros no cubren.

Elijas lo que elijas, evita las herramientas que guardan tus tests en un formato propietario. El día que quieras irte, los tests se van contigo o no eran tuyos.

Grabar o escribir

Hay dos formas de crear un test y las dos son legítimas.

Escribirlo a mano da control total. También exige que alguien del equipo sepa hacerlo y tenga tiempo. Un flujo de checkout completo son entre cuarenta y cien líneas.

Grabarlo es abrir la aplicación, hacer el recorrido una vez y dejar que la herramienta traduzca tus clics a código. Playwright trae esto de fábrica:

npx playwright codegen https://tu-app.com

Se abre un navegador, haces el flujo, y en la ventana de al lado aparece el spec.

La grabación tiene una trampa conocida: los selectores que genera suelen ser frágiles. Si el grabador escribe nth(4) o una clase autogenerada, ese test se rompe en el próximo despliegue. Lo tratamos en detalle en por qué se rompen los tests E2E.

La regla práctica: graba para tener el esqueleto rápido, después revisa los selectores y las aserciones a mano.

Los selectores: donde se decide todo

Un test E2E es tan estable como sus selectores. Este es el orden de preferencia, de mejor a peor:

1. Por rol accesible y texto — getByRole('button', { name: 'Confirmar compra' }). Sobrevive a los rediseños porque describe lo que el usuario ve.
2. Por atributo de prueba — getByTestId('checkout-submit'). Estable, pero exige que alguien ponga los data-testid en el código.
3. Por texto visible — getByText('Confirmar compra'). Bien, hasta que cambia el copy.
4. Por CSS o XPath — .btn-primary.submit-order. Se rompe con cualquier cambio de estilos.
5. Por posición — nth(4). Se rompe cuando alguien agrega un elemento arriba.

Si tus tests usan mayoritariamente los niveles 4 y 5, no tienes una suite: tienes deuda con apariencia de cobertura.

Esperar bien

La segunda causa de suites poco confiables son las esperas.

// mal: espera fija, o sobra tiempo o falta
await page.waitForTimeout(3000);

// mal: "sin peticiones de red" no significa "listo para el usuario"
await page.waitForLoadState('networkidle');

// bien: espera por la condición que te importa
await expect(page.getByText(/Orden #\d+/)).toBeVisible();

Una espera fija falla de dos maneras: si el servidor va lento, el test falla sin que haya un bug; si va rápido, desperdicias segundos en cada corrida. Multiplícalo por cincuenta tests y por diez corridas diarias.

Esperar por condición resuelve ambas: el test avanza en cuanto aparece lo que espera, y falla si no aparece nunca.

Dónde ejecutarlas

En la máquina del desarrollador está bien para escribir un test. Para todo lo demás, no.

Las pruebas E2E deben correr en un servidor aparte, sin interfaz gráfica, disparadas por cada cambio de código. Las razones son prácticas: no dependen de que alguien se acuerde, no bloquean la máquina de nadie durante diez minutos, y el resultado queda registrado.

Lo mínimo que necesitas de esa ejecución:

• Una captura por paso. Sin imágenes, un fallo es un mensaje de error sin contexto.
• El trace de la corrida. Playwright lo genera; permite rebobinar la ejecución.
• La duración de cada paso. Un paso que normalmente tarda dos segundos y hoy tardó doscientos milisegundos probablemente no se ejecutó.

Si tu integración continua solo te dice “pasó” o “falló”, te falta la mitad de la información.

Leer el resultado: el verde también se audita

Aquí es donde la mayoría de los equipos se relaja, y es el error más caro.

Un test que pasa no siempre probó algo. El selector pudo no encontrar el elemento, la aserción pudo no llegar a evaluarse, o alguien pudo envolver el paso en un try/catch que sigue de largo. El reporte dice SUCCESS y nadie mira más. Eso es un falso verde, y cuesta más que un test roto: un rojo se investiga, un verde falso se celebra y encima autoriza el despliegue.

Cuatro señales revelan un verde vacío:

• Pasos que nunca alcanzaron un estado estable.
• Menos capturas que pasos ejecutados.
• Cero aserciones de intención en toda la corrida.
• Una duración anormalmente baja.

Cómo verificarlas está en cómo detectar falsos verdes.

Mantenerla viva

Una suite E2E no se termina, se mantiene. Tres hábitos que marcan la diferencia:

Un test que falla a veces se arregla o se saca. Un test intermitente entrena al equipo a ignorar los rojos, y entonces la suite entera deja de servir. Cómo identificarlos: tests flaky.

Los datos de prueba se crean y se destruyen en el test. Si tu test depende de que exista el usuario pepito@test.com, va a fallar el día que alguien limpie la base.

La suite corre completa antes de cada despliegue. Si tarda demasiado para eso, el problema es que tarda demasiado, no que haya que correrla menos.

Un camino de dos semanas

Si empiezas de cero:

1. Días 1-2 — Elige los tres flujos críticos. Escríbelos en una hoja, paso a paso, en español.
2. Días 3-5 — Automatiza el primero. Grábalo, arregla los selectores, añade una aserción real sobre el resultado final.
3. Días 6-8 — Los otros dos.
4. Días 9-10 — Conéctalos a tu integración continua. Que corran solos en cada cambio.
5. Semana 2 — Obsérvalos. Arregla lo intermitente. Recién ahí agrega más flujos.

Tres tests confiables valen más que treinta que nadie mira.

Lo que hace Oráculo

Oráculo cubre este camino sin que tengas que escribir código: grabas el flujo desde el navegador, queda guardado como un spec de Playwright estándar —legible y tuyo—, y un worker lo ejecuta fuera de tu máquina devolviendo captura, trace y duración de cada paso.

Y hace la parte que casi ninguna herramienta hace: marca los verdes que no tienen evidencia detrás, para que un SUCCESS signifique algo.