Playwright vs Cypress vs Selenium en 2026: Comparación Honesta

Cypress no tiene soporte para Safari y cobra por la paralelización en CI por encima del nivel gratuito: dos limitaciones arquitectónicas que empujan a los equipos hacia Playwright cuando la cobertura multiplataforma importa o las suites crecen más allá de una sola máquina. Para equipos que no chocan con esas paredes, migrar desde una suite de Cypress que funciona cuesta más de lo que aporta. Este artículo cubre lo que cada framework hace bien, dónde falla cada uno, y cómo pensar la migración desde Selenium o Cypress cuando la decisión no es obvia.

La versión corta

Si empiezas un proyecto nuevo en 2026: Playwright. Si ya estás en Cypress con una suite que funciona: quédate, a menos que tengas una razón específica para migrar. Si estás en Selenium: evalúa si el costo de mantenimiento justifica seguir.

Selenium: el veterano

Selenium es el más antiguo de los tres y, por base instalada, sigue siendo el más usado. Millones de líneas de tests de Selenium corren en pipelines de CI hoy, y eso no va a cambiar rápido.

Lo que Selenium hace bien

La elección de lenguaje es genuina. Java, Python, C#, Ruby, JavaScript: Selenium los soporta todos con bindings maduros. Si tu equipo escribe en Java, Selenium con TestNG o JUnit es una opción legítima y bien documentada.

La cobertura multiplataforma es completa. Selenium soporta cualquier navegador con una implementación de WebDriver, incluyendo Internet Explorer y Edge Legacy. Si pruebas en navegadores que Playwright no soporta, Selenium puede ser tu única opción.

El ecosistema es enorme. Stack Overflow, tutoriales, librerías, integraciones: Selenium tiene más de 15 años de inversión de la comunidad.

Lo que Selenium hace mal

La gestión de drivers es una carga de mantenimiento constante. ChromeDriver debe coincidir con la versión de Chrome. Cuando Chrome se actualiza automáticamente, los tests se rompen hasta que actualizas el driver. Selenium Manager (introducido en Selenium 4) mejora esto, pero no elimina el problema del todo.

Sin espera integrada. Escribes el código de espera manualmente: WebDriverWait, ExpectedConditions, utilidades de polling personalizadas. Cada equipo reinventa esta rueda.

Overhead de configuración. Selenium es una librería, no un framework. Armas el framework de tests a partir de Selenium más un test runner (JUnit, pytest, Jest) más una librería de aserciones más un reporter. Playwright viene como paquete completo.

Velocidad. Los tests de Selenium son generalmente más lentos que los de Playwright en escenarios equivalentes.

// Selenium (Java): esperar un botón
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement btn = wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("button[data-testid='submit']")
));
btn.click();

// Playwright (TypeScript): la misma operación
await page.getByRole('button', { name: 'Submit' }).click();

Quién debería usar Selenium

Equipos con suites de Selenium existentes, equipos que escriben en Java/Python/C# donde el ecosistema importa, equipos que prueban en navegadores que Playwright no soporta.

Cypress: el punto medio amigable para desarrolladores

Cypress se lanzó alrededor de 2017 y llenó un hueco real: un framework de testing fácil de configurar con una gran experiencia para el desarrollador. Era la alternativa moderna a Selenium antes de que llegara Playwright.

Lo que Cypress hace bien

Experiencia del desarrollador. La interfaz del test runner de Cypress es excelente: ejecución de tests en tiempo real, depuración con viaje en el tiempo con snapshots del DOM, reproducción de tests integrada. Para desarrolladores que no viven en frameworks de testing, Cypress es fácil de adoptar.

Testing de componentes. Cypress tiene soporte de primera clase para probar componentes de React, Vue, Angular y Svelte en aislamiento. Si tu equipo escribe muchos tests de componentes, Cypress es competitivo.

Mensajes de error. Los errores de Cypress son claros y detallados. Te dicen exactamente qué elemento se encontró, cuál fue el timeout y cómo se ve el DOM en ese momento.

Lo que Cypress hace mal

Soporte de navegadores. Chromium está completamente soportado. Firefox tiene soporte limitado. WebKit (Safari) no está soportado. Si la cobertura multiplataforma importa, Cypress no puede proveerla.

La paralelización requiere pago. Ejecutar tests en múltiples máquinas en CI requiere Cypress Cloud. El nivel gratuito tiene límites. El sharding de Playwright es gratuito e integrado.

Escenarios multidominio y multipestaña. Cypress fue diseñado arquitectónicamente para testing mismo origen. Los redireccionamientos entre dominios (flujos OAuth, pagos de terceros) requieren soluciones alternativas. Playwright los maneja de forma nativa.

Sin emulación móvil. Playwright puede emular dispositivos, viewports, user agents, geolocalización y eventos táctiles. Cypress no puede.

El manejo de iframes es limitado. Playwright trata los iframes como contextos de navegador de primera clase. Cypress tiene soluciones alternativas que no siempre cubren todos los casos.

// Cypress: sin await, cola de comandos
cy.visit('https://lab.becomeqa.com')
cy.get('[data-cy="login-btn"]').click()
cy.get('input[name="username"]').type('admin@becomeqa.com')

// Playwright: async/await explícito
await page.goto('https://lab.becomeqa.com')
await page.getByRole('button', { name: 'Login' }).click()
await page.getByLabel('Username').fill('admin@becomeqa.com')

La diferencia arquitectónica es importante: Cypress usa una cola de comandos (los comandos se encolan y se ejecutan después, sin await). Playwright usa async/await estándar de JavaScript. Si conoces JavaScript moderno, el modelo de Playwright es más intuitivo. Si eres nuevo en programación asíncrona, el enfoque de Cypress elimina esa complejidad.

Quién debería usar Cypress

Equipos con suites de Cypress existentes, equipos que hacen testing de componentes intensivo, equipos donde la adopción por parte de los desarrolladores es la prioridad y la cobertura multiplataforma no importa.

Playwright: el estándar actual

Playwright está desarrollado y mantenido por Microsoft, lanzado en 2020, y ha crecido rápidamente.

Lo que Playwright hace bien

Auto-espera en todos lados. Cada interacción con un locator espera automáticamente a que el elemento sea accionable. Sin esperas explícitas para escenarios estándar.

Verdadera cobertura multiplataforma. Chromium, Firefox y WebKit ejecutan el mismo código de test sin configuración específica por navegador. Esto da cobertura real de Safari en Windows, que ninguna otra herramienta provee.

Soporte completo de TypeScript. Los tipos son de primera clase, no algo agregado después.

Interceptación de red. page.route() intercepta, modifica o simula cualquier petición de red. Útil para probar estados de error sin cambiar el backend.

// Simular una respuesta de API fallida
await page.route('**/api/items', route => {
  route.fulfill({ status: 500, body: '{"error": "Internal server error"}' });
});

Multipestaña y multi-contexto. Crear un nuevo contexto de navegador o una nueva pestaña es directo:

const newPage = await context.newPage();
await newPage.goto('https://lab.becomeqa.com/other-page');

Sharding gratuito. Distribuye la suite entre N máquinas sin ningún servicio externo:

npx playwright test --shard=1/4  # ejecutar el 25% de los tests en esta máquina

Testing de API integrado. El fixture request provee un cliente HTTP completo que comparte el contexto del navegador:

test('API + UI combinados', async ({ page, request }) => {
  const resp = await request.get('/api/items');
  expect(resp.status()).toBe(200);
});

Lo que Playwright hace menos bien

El testing de componentes es experimental. Playwright tiene soporte para testing de componentes, pero es menos maduro que el de Cypress.

La interfaz de Cypress es mejor para depuración interactiva. El modo UI de Playwright es bueno, pero la vista previa en vivo y la reproducción de snapshots del DOM de Cypress siguen siendo una mejor experiencia para desarrolladores que no son principalmente testers.

La comunidad es más joven. Menos historial en Stack Overflow, menos tutoriales para casos extremos.

Quién debería usar Playwright

Proyectos nuevos, equipos que necesitan cobertura multiplataforma, equipos que necesitan testing de API + UI en un solo framework, equipos que quieren paralelización gratuita.

Comparativa

| Característica | Selenium | Cypress | Playwright |

|---|---|---|---|

| Lenguajes | Java, Python, C#, JS, Ruby | JavaScript/TypeScript | JS/TS, Python, Java, .NET |

| Auto-espera | Manual | Integrada | Integrada |

| Navegadores | Todos + IE | Chromium, Firefox parcial | Chromium, Firefox, WebKit |

| Emulación móvil | No | No | Sí |

| Multipestaña | Complicado | Soluciones alternativas | Nativo |

| Mock de red | Parcial | Integrado | Integrado |

| Paralelización | Gratuita | Paga (Cloud) | Gratuita |

| Complejidad de configuración | Alta | Baja | Baja |

| Testing de componentes | No | Excelente | Experimental |

| Testing de API | No | No | Integrado |

| Tiempo de configuración | 30-60 min | 10 min | 10 min |

Migración: cuándo y si vale la pena

Selenium a Playwright

Vale evaluar si tu suite de Selenium tiene un alto costo de mantenimiento por la gestión de drivers y las utilidades de espera. La migración no es trivial. Los page objects y la lógica de tests se pueden portar, pero los locators necesitan reescribirse. Hazlo función por función, no todo de golpe.

Cypress a Playwright

Considéralo si llegaste al techo de soporte de navegadores, necesitas paralelización gratuita, o necesitas escenarios multipestaña/multidominio de forma regular. Si tu suite de Cypress funciona bien y no chocas con esas paredes, el costo de migración supera el beneficio.

Playwright a cualquier otra cosa

Difícil de justificar en 2026. Playwright está en desarrollo activo, bien soportado, y no tiene limitaciones arquitectónicas que fuercen una migración.

Preguntas frecuentes

No pronto. Hay demasiadas suites de tests existentes y demasiados equipos que han invertido en herramientas de Selenium. Pero para proyectos nuevos, ya no es la primera elección.

Puedes, pero no deberías. Duplica la superficie de dependencias y divide el conocimiento del equipo. Elige uno.

Playwright es generalmente el más rápido, especialmente con sharding paralelo entre máquinas. Cypress es comparable dentro de una sola máquina. Selenium es el más lento por el overhead del protocolo WebDriver.

Selenium sigue dominando en número bruto, impulsado por bases de código empresariales heredadas. Las ofertas para Playwright están creciendo rápido y se concentran en empresas que construyen proyectos nuevos. Si apuntas a empresas tech modernas, Playwright es cada vez más la habilidad esperada.