¿Por qué el "clic manual" ya no funciona?
\n\nImagine: ha terminado una función, presiona "Run" en el editor, en el navegador todo se ve perfecto. Lo publica en producción. Y una hora después, pánico: el formulario de registro se rompió porque alguien cambió accidentalmente una clase CSS y su colega no lo notó. ¿Le suena familiar? Si escribe en JavaScript y usa Python en el backend, seguramente se ha encontrado con situaciones en las que las pruebas E2E de aplicaciones JavaScript podrían haberle salvado la noche.
\n\nLas pruebas End-to-End (E2E) no son un lujo, sino una higiene básica para cualquier proyecto serio. Simulan las acciones de un usuario real: clics, ingreso de datos, desplazamiento, verificación de respuestas del servidor. Y sí, funcionan con su stack, ya sea React, Vue, Angular o simplemente JS vanilla.
\n\nEn este artículo, analizaremos cómo implementar pruebas integrales de aplicaciones web sin dolor, utilizando herramientas modernas. Verá ejemplos de código real en JavaScript, aprenderá cómo hacer que E2E se lleve bien con un backend de Python y obtendrá una lista de verificación para la implementación. ¡Allá vamos!
\n\n¿Qué son las pruebas E2E y por qué las necesita?
\n\nLas pruebas E2E (End-to-End) son el proceso de verificar todo el recorrido del usuario de principio a fin. Por ejemplo: abrir el sitio → buscar un producto → agregarlo al carrito → realizar el pedido → verificar que llegó un correo electrónico.
\n\nA diferencia de las pruebas unitarias (que verifican una sola función) o las pruebas de integración (que verifican la conexión de dos módulos), las pruebas integrales de JavaScript verifican todo el sistema: frontend, backend, base de datos, API externas.
\n\nCuándo son especialmente necesarias las pruebas E2E
\n- \n
- Está reescribiendo código antiguo en un nuevo framework. \n
- Tiene una arquitectura de microservicios + Python en el backend. \n
- Publica versiones con frecuencia y teme la regresión. \n
- Los clientes se quejan de "fallos" que no se reproducen localmente. \n
Sin E2E, corre el riesgo de enterarse de un error por parte del usuario. Con E2E, se entera un minuto antes del despliegue.
\n\nEligiendo la herramienta: Playwright vs Cypress
\n\nEn el mercado hay dos actores principales para la automatización de pruebas JavaScript: Playwright (de Microsoft) y Cypress (de la empresa del mismo nombre). Ambos son potentes, pero tienen matices.
\n\nPlaywright
\n- \n
- Compatible con todos los navegadores: Chromium, Firefox, WebKit (Safari). \n
- Funciona con iframes, pestañas, múltiples páginas. \n
- Se escribe en JS/TS, Python, C#, Java. \n
- Ideal para escenarios complejos: carga de archivos, interceptación de solicitudes de red, emulación de dispositivos móviles. \n
Cypress
\n- \n
- Sintaxis más simple, panel integrado. \n
- Solo funciona en Chromium (y Firefox experimentalmente). \n
- No puede abrir varias pestañas. \n
- Ideal para proyectos pequeños y un inicio rápido. \n
Nuestra elección para el artículo es Playwright, ya que está más cerca de los desarrolladores de Python (tiene una API oficial de Python) y cubre el 99% de los escenarios. Pero también mostraremos Cypress con un ejemplo.
\n\nEscribiendo la primera prueba E2E en Playwright (JavaScript)
\n\nLa instalación es sencilla:
\nnpm init -y\nnpm install @playwright/test\nnpx playwright install\n\nAhora creemos un archivo tests/example.spec.js. Supongamos que estamos probando la página de inicio de sesión del sitio pythonlib.ru (sí, es un ejemplo ficticio, pero la lógica es real).
const { test, expect } = require('@playwright/test');\n\ntest('El usuario puede iniciar sesión', async ({ page }) => {\n // 1. Abrimos la página de inicio de sesión\n await page.goto('https://pythonlib.ru/login');\n\n // 2. Rellenamos los campos\n await page.fill('#email', 'test@example.com');\n await page.fill('#password', 'securePassword123');\n\n // 3. Hacemos clic en el botón "Iniciar sesión"\n await page.click('button[type="submit"]');\n\n // 4. Esperamos la redirección al panel\n await page.waitForURL('**/dashboard');\n\n // 5. Verificamos que