Playwright vs Selenium vs Cypress: comparativa práctica para elegir framework de automatización

Cada vez que alguien arranca con automatización de pruebas aparece la misma pregunta: ¿cuál de los tres? La respuesta corta es que no hay un ganador universal, pero sí hay decisiones que se vuelven obvias cuando entendés cómo funciona cada uno por dentro. Casi todas las diferencias prácticas salen de ahí.

---

La diferencia de fondo: la arquitectura

Selenium habla con el navegador desde afuera usando WebDriver, que es un estándar del W3C. Tu código le manda órdenes a un driver, el driver se las pasa al navegador. Al ser un estándar abierto, cualquier navegador que lo implemente funciona — por eso Selenium corre en prácticamente todos lados, incluso en navegadores viejos o de nicho.

Cypress hace lo contrario: corre adentro del navegador, en el mismo event loop que tu aplicación. Eso le da un acceso privilegiado al estado de la app y una experiencia de depuración muy superior. También le impone límites que no son bugs, son consecuencias del diseño.

Playwright va por afuera como Selenium, pero en vez del protocolo estándar usa los protocolos de depuración nativos de cada navegador, con una conexión persistente. Gana velocidad y control fino (interceptar red, múltiples pestañas, varios orígenes) a cambio de depender de los navegadores que el equipo de Playwright mantiene.

---

Tabla comparativa

	Selenium	Cypress	Playwright
Lenguajes	Java, Python, C#, Ruby, JS, Kotlin	Solo JS/TS	JS/TS, Python, Java, .NET
Navegadores	Todos los que implementen WebDriver	Chrome, Firefox, Electron (WebKit experimental)	Chromium, Firefox y WebKit
Espera automática	No, la manejás vos	Sí, integrada	Sí, integrada
Paralelismo	Con Selenium Grid	Requiere Cypress Cloud u orquestación propia	Incluido y gratuito
Varias pestañas / orígenes	Sí	Limitado por diseño	Sí, nativo
Madurez del ecosistema	La mayor, desde 2004	Media	Creciendo rápido
Curva de aprendizaje	Más empinada	La más amable	Intermedia

---

El mismo test en los tres

Nada explica mejor las diferencias que ver el mismo caso escrito tres veces. Login y verificación de que llegamos al panel.

Selenium (Python)

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.get("https://ejemplo.com/login")

driver.find_element(By.ID, "usuario").send_keys("[email protected]")
driver.find_element(By.ID, "password").send_keys("secreto")
driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()

# La espera es explícita: si no la ponés, el test es inestable.
WebDriverWait(driver, 10).until(
    EC.text_to_be_present_in_element((By.CSS_SELECTOR, "h1"), "Panel")
)

driver.quit()

Cypress

it('inicia sesión correctamente', () => {
  cy.visit('/login')
  cy.get('#usuario').type('[email protected]')
  cy.get('#password').type('secreto')
  cy.get('button[type=submit]').click()

  // No hay waits: cada comando reintenta hasta que se cumple o expira.
  cy.get('h1').should('contain', 'Panel')
})

Playwright

test('inicia sesión correctamente', async ({ page }) => {
  await page.goto('/login')
  await page.getByLabel('Usuario').fill('[email protected]')
  await page.getByLabel('Contraseña').fill('secreto')
  await page.getByRole('button', { name: 'Entrar' }).click()

  // Los selectores por rol sobreviven a cambios de maquetado.
  await expect(page.getByRole('heading')).toHaveText('Panel')
})

Fíjense en el detalle que más impacta en el día a día: en Selenium la espera es responsabilidad tuya. En los otros dos viene de fábrica. Esa sola diferencia explica buena parte de los tests inestables que se ven en proyectos con Selenium mal armado.

---

Cuándo elegir cada uno

Selenium si:

• Tu equipo trabaja en Java, C# o Ruby y no vas a migrar a JS
• Necesitás cubrir navegadores fuera de los tres grandes, o versiones viejas
• Ya tenés infraestructura de Grid montada y funcionando
• Vas a compartir base con automatización mobile: Appium se construye sobre WebDriver

Cypress si:

• El equipo es de frontend y vive en JS/TS
• La prioridad es que la gente escriba tests rápido y sin fricción
• Querés testing de componentes junto con el end-to-end, en la misma herramienta
• Tu app no depende de múltiples pestañas ni de saltar entre dominios

Playwright si:

• Arrancás un proyecto desde cero hoy
• Necesitás Safari/WebKit de verdad, no una aproximación
• El paralelismo importa y no querés pagar por él
• Tenés escenarios complejos: varias pestañas, varios orígenes, interceptar red

---

Cosas que no suelen aparecer en las comparativas

La herramienta no arregla una mala estrategia. Un test suite lento y frágil en Selenium va a seguir siendo lento y frágil en Playwright si el problema son los selectores acoplados al DOM, la falta de datos de prueba controlados o testear por la interfaz cosas que se testean mejor por API.

El costo de migrar es real. Cambiar de framework no es solo reescribir tests: es reescribir helpers, fixtures, integración con CI, reportes y la costumbre del equipo. Si lo que tenés funciona, la pregunta no es "cuál es mejor" sino "qué problema concreto me está costando plata".

La brecha se está achicando. WebDriver BiDi es el estándar que busca darle a Selenium las capacidades bidireccionales que hoy son ventaja de Playwright. En un par de años varias de estas diferencias van a pesar menos.

El mejor selector es el que no depende del CSS. Independientemente del framework: roles de accesibilidad, etiquetas y atributos dedicados de test envejecen mucho mejor que una cadena de clases.

---

Cierre

Si tuviera que resumirlo en una línea: Playwright es la opción por defecto para proyectos nuevos, Cypress gana cuando la prioridad es que el equipo de frontend adopte testing sin resistencia, y Selenium sigue siendo imbatible en diversidad de lenguajes, navegadores y escenarios corporativos.

¿Ustedes qué están usando? Me interesa especialmente escuchar casos de migración: qué los empujó a cambiar y si valió la pena. Y si están arrancando y no saben por dónde, cuenten el contexto (lenguaje del equipo, tipo de app, si hay CI) y vemos entre todos.

Artículo elaborado con asistencia de IA y revisado antes de publicar.