Selenium, Cypress o Playwright: cuál elegir y por qué

Qué hacen las tres y qué no

Las tres herramientas resuelven el mismo problema: abrir un navegador de verdad, actuar sobre una página como lo haría una persona y comprobar que el resultado es el esperado. Ese tipo de prueba se llama de extremo a extremo (o end to end, abreviado E2E): recorre el sistema completo, desde el clic hasta la base de datos y de vuelta.

Conviene decir también qué no son. No reemplazan a las pruebas unitarias ni a las de integración: son la punta de la pirámide, la parte más lenta y frágil, y por eso se reservan para los caminos críticos. Si esa distinción te suena nueva, arrancá por la guía de testing de software desde cero.

Un aviso de vocabulario: Selenium es una familia de proyectos y acá hablamos de Selenium WebDriver, su biblioteca de automatización. Cypress y Playwright, en cambio, son marcos completos que traen ejecutor de pruebas, aserciones e informes en la misma caja.

La diferencia de fondo: cómo le hablan al navegador

Casi todas las diferencias prácticas —qué lenguaje podés usar, por qué una espera sola y la otra no, por qué una no abre dos pestañas— salen de una sola decisión de diseño: dónde vive el código de la prueba y cuántas piezas hay entre ese código y el navegador.

Leído de arriba hacia abajo, el diagrama muestra tres modelos:

• Selenium — tres piezas. Tu código envía órdenes por HTTP a un driver, un programa aparte específico de cada navegador (chromedriver, geckodriver), y ese driver mueve el navegador. Es la arquitectura más indirecta y también la única normalizada.
• Cypress — la prueba adentro. Un proceso de Node arranca el navegador y hace de intermediario en el tráfico; tu código de prueba se ejecuta dentro de ese navegador, en el mismo run loop que la aplicación. Por eso puede leer el window, el document y los temporizadores de la página como si fuera parte de ella.
• Playwright — control directo. Tu código corre afuera y le habla al navegador por un protocolo propio sobre WebSocket, sin driver intermedio. El navegador no es el que tenés instalado: Playwright descarga y usa sus propias compilaciones de Chromium, Firefox y WebKit.

Selenium: el estándar del W3C

Selenium WebDriver es, según su propia documentación, «una API y un protocolo que definen una interfaz neutral respecto del lenguaje para controlar el comportamiento de los navegadores». Esa neutralidad no es marketing: WebDriver es una especificación del W3C, cuya revisión más reciente al momento de escribir esta guía es el borrador de trabajo del 2 de julio de 2026. Ninguna de las otras dos herramientas implementa un estándar abierto de ese tipo.

Eso tiene una consecuencia concreta: los navegadores traen soporte de WebDriver porque el estándar existe, no porque Selenium lo pida. Y permite que las mismas órdenes funcionen desde Java, Python, C#, Ruby y JavaScript, los cinco lenguajes con bindings oficiales del proyecto.

Lo que cambió y casi nadie actualizó en su cabeza

La queja histórica contra Selenium era el mantenimiento de los drivers: cada actualización de Chrome rompía la suite hasta que alguien descargaba el chromedriver nuevo. Eso está resuelto desde la versión 4.6, que incorporó Selenium Manager: una herramienta escrita en Rust que se distribuye con cada versión, detecta el navegador instalado, descarga el driver compatible y lo guarda en caché sin configuración. Funciona como respaldo, así que si tu proyecto ya declara un driver a mano, ese conserva la prioridad. La documentación oficial todavía la etiqueta como beta.

Qué te toca armar a mano

Selenium WebDriver automatiza el navegador y nada más. El ejecutor de pruebas, las aserciones, los informes, la ejecución en paralelo y las capturas al fallar los aportás vos combinándolo con otras herramientas —JUnit, TestNG, pytest, NUnit— o con Selenium Grid para distribuir la ejecución. Es la parte que más sorprende a quien llega desde Cypress o Playwright: ahí ese andamiaje viene puesto.

Cypress: la prueba corre adentro

Cypress invierte el modelo. Su documentación lo dice sin rodeos: la mayoría de las herramientas «operan corriendo fuera del navegador y ejecutando órdenes remotas por la red», mientras Cypress se ejecuta «en el mismo run loop que tu aplicación». Un proceso de Node acompaña al navegador, así que la herramienta ve las dos mitades del sistema a la vez.

El beneficio se nota el primer día: la prueba se detiene en el paso que falló con la aplicación viva delante, y se puede recorrer el historial de comandos e inspeccionar el DOM en cada instante. Para equipos de frontend que ya viven en JavaScript, la curva de entrada es la más corta de las tres.

Los cuatro límites que conviene conocer antes de empezar

Cypress publica una página de trade-offs donde separa las limitaciones permanentes —consecuencia directa de su arquitectura— de las temporales. Las permanentes son las que deciden si la herramienta te sirve:

• Solo JavaScript. El código corre en el navegador, así que no hay Python, Java ni C#. Para hablar con el backend o la base de datos hay que salir por cy.exec(), cy.task() o cy.request().
• Un navegador a la vez. Cypress no controla más de un navegador abierto simultáneamente, lo que descarta los escenarios de colaboración entre dos usuarios reales.
• Un superdominio por prueba. Cada prueba queda atada a un superdominio; para cruzar a otro origen hay que usar el comando cy.origin().
• Sin eventos nativos ni móviles. No hay soporte de eventos del sistema operativo ni de gestos móviles, y los iframe de otro origen tienen soporte parcial.

La propia documentación defiende varias de estas restricciones como una forma de empujar hacia pruebas más rápidas y menos frágiles. Es un argumento razonable, pero conviene evaluarlo contra tu producto real: si tu flujo de pago redirige a la pasarela de un tercero y vuelve, esa restricción no es filosófica, es trabajo extra.

Un detalle revelador sobre Safari

Cypress ofrece soporte experimental de WebKit, el motor de Safari, que hay que activar con la opción experimentalWebKitSupport. Lo interesante es cómo: requiere instalar el paquete playwright-webkit. Es decir, para probar en el motor de Safari, Cypress usa la compilación de WebKit que mantiene Playwright.

Playwright: control directo, sin driver

Playwright es el más joven de los tres y su diseño se lee como una respuesta a los problemas de los otros dos. Se define como un marco de pruebas de extremo a extremo que «empaqueta ejecutor, aserciones, aislamiento, paralelización y herramientas» en un solo lugar.

Trae sus propios navegadores

Playwright descarga e instala sus propias compilaciones de Chromium, Firefox y WebKit, y las guarda en una caché del sistema. Esto explica de un tirón dos cosas que suelen confundir:

• Por qué anda igual en Windows, Linux y CI: el motor de Safari viaja con la herramienta en lugar de depender de macOS.
• Por qué no usa tu Firefox ni tu Safari: sus compilaciones llevan parches propios, y la documentación aclara que no funciona con las versiones de marca de esos navegadores. Para Chrome y Edge sí puede usar la instalación del sistema mediante channels (chrome, msedge).

Ese es el matiz honesto de Playwright: probás el motor de Safari, no Safari. Para la enorme mayoría de los defectos de rendering y comportamiento alcanza; para certificar el navegador tal como lo recibe quien lo usa, no.

Espera automática y diagnóstico

La característica que más reduce pruebas flaky es la espera automática: antes de actuar sobre un elemento, Playwright comprueba que sea accionable —visible, estable, habilitado, no tapado— y reintenta hasta que lo sea o se agote el tiempo. Las aserciones siguen la misma lógica y reintentan solas. En Selenium ese comportamiento hay que escribirlo con esperas explícitas.

Suma dos herramientas de diagnóstico que ahorran horas: Codegen, que graba tus clics y escribe el código de la prueba, y el Trace Viewer, que guarda una traza navegable de la ejecución con capturas, DOM, red y consola en cada paso. Es lo que permite entender un fallo de CI sin reproducirlo localmente.

Comparación lado a lado

Los datos de versión y licencia corresponden a lo publicado en los registros oficiales de paquetes el 27 de julio de 2026. Las versiones cambian seguido; el resto de las filas es estructural y se mueve mucho más despacio.

Una fila que suele pedirse y no está acá a propósito: la velocidad. Comparar tiempos de ejecución de forma honesta exige fijar aplicación, red, hardware y tipo de prueba, y cualquier número sin ese contexto se vuelve propaganda. Lo que sí se puede afirmar es estructural: Selenium agrega un salto de red por cada orden que envía al driver, y ni Cypress ni Playwright tienen ese salto.

El mismo test en las tres

Nada explica mejor las diferencias que un caso idéntico escrito tres veces. El caso es este portal: abrir el índice de guías, escribir wardriving en el buscador y comprobar que el contador de resultados queda en una sola guía. Es un buen ejemplo porque el filtrado ocurre en el cliente, sin recargar la página, y una prueba mal escrita comprobaría el contador antes de que se actualice.

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

# Desde 4.6 no hace falta descargar el driver: lo resuelve Selenium Manager
driver = webdriver.Chrome()
try:
    driver.get("https://underc0de.org/guias/")
    driver.find_element(By.CSS_SELECTOR, "[data-guide-search]").send_keys("wardriving")

    # La espera es explícita: hay que pedirla, no viene sola
    WebDriverWait(driver, 10).until(
        EC.text_to_be_present_in_element(
            (By.CSS_SELECTOR, "[data-result-count]"), "1 guía encontrada"
        )
    )
finally:
    driver.quit()

Notá lo que falta: no hay ejecutor de pruebas, no hay aserción propia de la biblioteca y hay que cerrar el navegador a mano en un finally. Eso se combina después con pytest o JUnit.

describe("Índice de guías de Underc0de", () => {
  it("el buscador deja una sola guía al filtrar por wardriving", () => {
    cy.visit("https://underc0de.org/guias/");
    cy.get("[data-guide-search]").type("wardriving");

    // should() reintenta solo hasta que el texto coincida o se agote el tiempo
    cy.get("[data-result-count]").should("have.text", "1 guía encontrada");
  });
});

Ejecutor, aserciones y espera vienen incluidos, y el encadenamiento de comandos hace que la prueba se lea casi como una narración. El precio está fuera del ejemplo: esto es JavaScript y no puede ser otra cosa.

import { test, expect } from "@playwright/test";

test("el buscador deja una sola guía al filtrar por wardriving", async ({ page }) => {
  await page.goto("https://underc0de.org/guias/");
  await page.locator("[data-guide-search]").fill("wardriving");

  // expect() sobre un locator reintenta hasta que la condición se cumpla
  await expect(page.locator("[data-result-count]")).toHaveText("1 guía encontrada");
});

El mismo caso, cuatro líneas y una diferencia conceptual importante: un locator de Playwright no es un elemento capturado, es una descripción de cómo encontrarlo, que se resuelve de nuevo en cada intento. Es lo que evita el error clásico de Selenium en páginas dinámicas, cuando el elemento guardado desaparece del DOM y la referencia queda huérfana.

Cómo elegir sin arrepentirte

La elección se vuelve fácil cuando se hace en orden y con preguntas cerradas, en lugar de comparar listas de funcionalidades. Estas tres preguntas alcanzan para la mayoría de los casos: la primera que contestes «sí» decide.

Y una variable que no aparece en ninguna comparativa pero decide más que todas las demás: quién va a escribir y mantener estas pruebas. Una herramienta que el equipo no domina produce una suite que nadie arregla, y una suite que nadie arregla se termina desactivando. Si tu equipo todavía está construyendo esa base, la ruta para aprender a programar es una inversión más rentable que cambiar de marco.

Lo que ya se discutió en Underc0de

Esta pregunta no es nueva en la comunidad. En junio de 2024, Agusreynoso abrió en el foro el hilo «Cypress o Selenium?» para decidir con cuál empezar. La respuesta más desarrollada fue la de ANTRAX, que recomendó Playwright por encima de las dos opciones planteadas: mencionó los navegadores que se actualizan solos, el soporte de varios lenguajes, la posibilidad de probar API junto a la interfaz, el manejo de varias pestañas y la espera incorporada. En el mismo hilo, otra persona señaló que en su mercado seguían pidiendo más Selenium y Cypress.

Dos años después, ese diagnóstico se sostiene bien contra la documentación oficial, con dos precisiones que conviene hacer. La primera: Playwright tiene cuatro lenguajes oficiales —JS/TS, Python, Java y .NET—; Ruby no está entre ellos. La segunda: el problema de sincronizar el driver con la versión del navegador, que en el hilo aparece como argumento contra Selenium, había quedado resuelto en 2022 con la llegada de Selenium Manager. Es un buen recordatorio de que las comparativas envejecen más rápido que las herramientas.

En la sección de QA del foro hay además material práctico: Mr. Bones publicó en 2023 una serie de capítulos sobre Playwright y otra sobre Cypress con el patrón de tres fases —preparar el estado, actuar, afirmar— que hoy se usa igual. Luca Ahumada compartió Playc0de, un marco construido sobre Playwright. Y el aporte más antiguo es de 2017: Mortal_Poison escribió un tutorial de Selenium con Python que sigue sirviendo como introducción conceptual, aunque su código usa los métodos find_element_by_* que Selenium eliminó en 2022.

Errores frecuentes al elegir

• Elegir por comparativas sin fecha. Buena parte de lo que se lee sobre Selenium describe la versión 3, anterior a 2018. Antes de creer una desventaja, comprobá si sigue vigente en la documentación actual.
• Descartar una herramienta por una limitación que no te afecta. Que Cypress no abra dos navegadores a la vez es irrelevante si tu producto no tiene ningún flujo entre dos usuarios simultáneos.
• Confundir «probar WebKit» con «probar Safari». Sirve para casi todo, pero no es lo mismo, y conviene decirlo antes de prometer cobertura de Safari a alguien.
• Automatizar por la interfaz lo que se ve mejor en la API. Es el error más caro: pruebas lentas y frágiles para verificar reglas de negocio que una petición HTTP comprueba en milisegundos.
• Medir el éxito en cantidad de pruebas. Doscientas pruebas E2E que tardan cuarenta minutos y fallan al azar dan menos información que veinte estables y bien elegidas.
• Postergar la decisión probando las tres «un poco». Terminás con tres configuraciones a medias y ninguna suite que el equipo confíe.

Preguntas frecuentes

Fuentes

Documentación oficial, especificaciones y registros de paquetes consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

1. Selenium. WebDriver — documentación oficial. Definición de WebDriver como API y protocolo neutral respecto del lenguaje, y bindings oficiales.
2. Selenium. Selenium Manager (Beta). Gestión automática de drivers incluida por defecto desde la versión 4.6.
3. SeleniumHQ, en GitHub. [py]: remove deprecated find_element_by_ methods. Eliminación de los métodos antiguos de localización en las bindings de Python.
4. W3C. WebDriver — W3C Working Draft, 2 de julio de 2026. Especificación del protocolo que implementa Selenium.
5. W3C. WebDriver BiDi — W3C Working Draft. Protocolo bidireccional en desarrollo para automatización de navegadores.
6. Cypress. Why Cypress?. Arquitectura de ejecución dentro del navegador y en el mismo run loop que la aplicación.
7. Cypress. Trade-offs. Limitaciones permanentes y temporales declaradas por el proyecto.
8. Cypress. Launching Browsers. Navegadores soportados y soporte experimental de WebKit.
9. Playwright. Browsers. Compilaciones propias de Chromium, Firefox y WebKit, y uso de canales de Chrome y Edge.
10. Playwright. Languages. Los cuatro lenguajes con soporte oficial.
11. Playwright. Auto-waiting. Comprobaciones de accionabilidad previas a cada acción.
12. Underc0de, foro. «Cypress o Selenium?», iniciado por Agusreynoso el 25 de junio de 2024, con la respuesta de ANTRAX. Hilo de la comunidad que originó el enfoque de esta guía.
13. Underc0de, foro. «01 - Playwright - Capítulo piloto», por Mr. Bones, 16 de septiembre de 2023, sección QA. Serie práctica sobre Playwright.
14. Underc0de, foro. «Selenium: aprende a crear tus propios bots con Python», por Mortal_Poison, 5 de octubre de 2017. Aporte histórico, con la API anterior a Selenium 4.
15. Notas de versión y registros oficiales. Playwright release notes, Cypress changelog y selenium en PyPI. Versiones vigentes al 27 de julio de 2026; las licencias figuran en los repositorios de Playwright y Cypress.