e2e es un framework open source de pruebas end to end (E2E) con IA: describes un objetivo en lenguaje natural, un agente recorre tu app web o móvil y, una vez verificado el resultado, sus acciones se repiten sin llamar al modelo hasta que la interfaz cambia.
Ese mecanismo es toda la propuesta. La mayoría de las herramientas de AI testing pagan inferencia en cada ejecución. e2e paga una vez, guarda lo que funcionó y solo vuelve al modelo cuando la pantalla ya no coincide con la grabación. Lo publica TesterArmy bajo licencia Apache-2.0.
¿Qué es e2e y cómo funcionan sus pruebas end to end con IA?
e2e es un runner de tests, un SDK y una CLI, publicado en npm como e2e. Para web controla Chromium, Firefox y WebKit a través de Playwright; para móvil, simuladores de iOS y emuladores de Android. En un mismo test puedes combinar tres tipos de pasos:
- Objetivos para el agente:
agent.act('upgrade the workspace to the Pro plan') - Verificaciones juzgadas por IA:
agent.assert('the invoice preview shows a prorated amount') - Assertions deterministas de siempre:
expect(screen.getByRole('status')).toContainText('Pro')
Un test sin pasos de agente no necesita ningún modelo. Eso importa: puedes adoptar e2e como un runner de e2e testing convencional y sumar IA solo en los flujos donde los selectores escritos a mano se rompen una y otra vez.
¿Cómo ahorra llamadas al modelo la caché de repetición?
La caché graba las acciones de un paso agent.act() solo después de que una verificación posterior pasa: una assertion sobre un locator, una comprobación de URL o un agent.assert. En la siguiente ejecución, el runner:
- Comprueba que la pantalla inicial sea la misma ruta.
- Busca cada control grabado (por rol, nombre, test id y contexto) y repite su acción.
- Verifica la ruta final y los controles que aparecieron, desaparecieron o cambiaron de estado.
- Si todo coincide, termina el paso sin llamar al modelo. Si algo no coincide, el agente retoma desde la pantalla actual.
El resumen de cada ejecución indica cuántos pasos se repitieron (replayed), cuántos se traspasaron al agente a mitad de camino (handed off) y cuántos se ejecutaron desde cero (missed).
Detalles que conviene conocer antes de contar con el ahorro:
- Las verificaciones no se cachean.
agent.assert,agent.waitForyagent.extractsiempre se ejecutan en vivo. El ahorro está en los pasos de acción, no en los juicios: un test lleno de assertions con IA sigue llamando al modelo en cada ejecución. - Los valores dinámicos necesitan
unique(). Un timestamp o un email nuevo provocarían un fallo de caché en cada ejecución; envolverlos enunique()hace que el runner sustituya el valor actual al repetir. - En CI la caché es de solo lectura por defecto. En local lee y escribe; en CI solo repite, salvo que configures
cache: 'read-write'. - La caché no se comparte por defecto.
e2e initagrega.e2e/cache/al.gitignore. Para compartir grabaciones con CI, quita esa línea, haz commit del directorio y revisa las entradas como revisarías código de test. - Las grabaciones obsoletas pueden fallar de forma visible. Sin configuración extra, si una grabación deja de funcionar el agente toma el paso en silencio y cada ejecución en CI vuelve a pagar llamadas al modelo. Con
--strict-cache, eso se convierte en un falloREPLAY_STALE.
¿Cómo se instala e2e?
En el directorio de tu app:
npx e2e init
npx e2e run
El asistente de init te pide un motor (web o móvil) y un proveedor de modelo, o None si quieres tests sin IA, y escribe e2e.config.ts y un test de ejemplo. El primer run descarga un navegador o arranca un simulador, comprueba que la app abre y escribe .e2e/report.json. No hace llamadas al modelo, así que todavía no necesitas una API key.
Requisitos: Node.js 24.8 o superior (22.22.3 o superior en la línea 22). Las pruebas móviles requieren además Xcode con un runtime de simulador iOS, o el Android SDK con un emulador.
¿Funciona e2e en Windows?
No de forma nativa: la documentación indica ejecutarlo dentro de WSL.
¿Se puede usar desde Claude Code, Codex o Cursor?
Sí, y es probablemente la forma más rápida de empezar. La guía de inicio incluye un prompt que pegas en Claude Code, Codex, Cursor u otro agente de código: el agente ejecuta init, instala la skill de e2e, apunta la configuración a tu servidor de desarrollo, te pregunta qué modelo usar e itera hasta que el test de ejemplo pasa.
Después, peticiones como “agrega un test para el checkout” o “¿por qué falló esta ejecución?” funcionan sin más configuración. e2e también incluye un servidor MCP (e2e mcp) para que tu agente de código inspeccione la app y la maneje en vivo mientras escribe el test, y el paquete trae toda la documentación en node_modules/e2e/docs para que el agente la lea sin conexión.
¿Es gratis e2e y qué modelos puede usar?
El framework es gratuito y open source; lo que se paga, si corresponde, es el uso del modelo en los pasos de agente. Hay tres caminos:
Suscripciones que ya tienes, sin API key:
| Suscripción | Comando |
|---|---|
| ChatGPT Plus o Pro | npx e2e login openai |
| GitHub Copilot | npx e2e login github-copilot |
| OpenCode Console | npx e2e login opencode-console |
| SuperGrok o X Premium+ | npx e2e login spacexai |
API keys de cualquier proveedor del Vercel AI SDK: Anthropic, OpenAI, Google, Mistral, DeepSeek y OpenRouter, entre muchos otros. Claude está disponible por esta vía, con API key, no con login de suscripción.
Modelos locales con Ollama, LM Studio o cualquier endpoint compatible con OpenAI, como vLLM o llama-server.
Un consejo: deja que el asistente de init escriba la línea del modelo en lugar de copiar un ID de modelo de un artículo. Los IDs cambian más rápido que la documentación.
¿e2e, Playwright, Cypress o Selenium?
No tienes que elegir de golpe. @e2e-dev/web trae su propio playwright-core fijado, así que tu @playwright/test no se toca y ambos runners conviven en el mismo proyecto; e2e busca tests/**/*.e2e.ts por defecto, de modo que los patrones de archivo no chocan. La documentación incluye guías de migración desde Playwright, Cypress, Selenium, Detox y Maestro.
La guía de Playwright muestra bien el intercambio. Un test de checkout con siete líneas guionizadas (navegar, clic en Checkout, completar tarjeta, vencimiento y CVC, clic en Pay, assertion final) queda así en e2e:
test('checkout', async ({ app, agent, screen }) => {
await app.open('/cart');
await agent.act('pay with the test card 4242 4242 4242 4242, expiry 12/30, CVC 123');
await expect(screen.getByRole('heading')).toHaveText('Order confirmed');
});
La navegación y la assertion final siguen siendo deterministas; el agente resuelve el formulario intermedio y se adapta si cambia. La propia guía recomienda empezar por flujos cuyos pasos cambian a menudo, como asistentes y checkouts, y dejar donde están los tests de Playwright que ya son estables.
También es honesta sobre lo que falta: todavía no hay snapshots de comparación de píxeles, los tests de un mismo archivo no corren en paralelo y no existe un reporter HTML. Además, los locators con texto buscan coincidencia exacta y distinguen mayúsculas, a propósito, mientras que Playwright busca subcadenas.
¿Qué debes saber antes de adoptarlo?
- Es pre-1.0. Al momento de publicar esta nota (octubre de 2026), el README indica que el proyecto está en desarrollo activo rumbo a la 1.0 y que las APIs y la configuración aún pueden cambiar entre versiones menores. Fija la versión.
- Los secretos quedan fuera de la vista del modelo. Las contraseñas se pasan como un handle
Secretque el modelo nunca ve, y tras rellenar un secreto se desactivan las capturas de pantalla durante el resto del test. - El código de test no corre en sandbox. Los tests y la configuración se ejecutan con los permisos de tu sistema operativo. La documentación de seguridad recomienda correr el código de pull requests no confiables en un sandbox externo, sin secretos.
- La telemetría viene activada. La CLI envía datos de uso anónimos. Para desactivarla:
npx e2e telemetry disableoE2E_TELEMETRY_DISABLED=1. - Hay una empresa detrás. TesterArmy vende una plataforma de testing agéntico alojada. El framework es Apache-2.0 completo, pero los enlaces del README apuntan al producto comercial.
¿Vale la pena probarlo?
Si tienes una suite end to end en la que cada rediseño rompe una docena de selectores por sprint, sí. La idea central es correcta: usa el modelo para la parte que cambia y deja de pagar por la que no cambia. Empieza con un solo flujo frágil, haz commit de la caché, corre CI con --strict-cache y mira cómo sube el contador de pasos repetidos.
¿Y tú? ¿Qué flujo de tu app rompe tus tests end to end cada vez que cambia la interfaz?
- Playwright
- Cypress
- Selenium
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Qué Cambia con GitHub Copilot Browser Tools