Playwright vs Cypress vs Selenium: cuál elegir en 2026

Esta comparativa no va de cuál tiene más estrellas en GitHub. Va de cuál te conviene aprender según lo que quieres hacer, qué stack tienes alrededor y qué buscan las empresas en España ahora mismo.

Los tres frameworks funcionan. Los tres tienen comunidad, documentación y ofertas de trabajo. La pregunta no es cuál es el mejor en abstracto, sino cuál tiene sentido para ti en este momento.

Vamos a verlo con sintaxis real, una tabla comparativa y un árbol de decisión claro al final. Sin hype.

Un vistazo rápido a cada uno antes de entrar en detalle

Selenium lleva desde 2004 en el mercado. Es el veterano. Surgió como herramienta interna de ThoughtWorks, se convirtió en el estándar durante una década y todavía tiene una presencia enorme en empresas con suites de pruebas antiguas. Funciona con Java, Python, C#, Ruby y JavaScript, lo que lo hace muy flexible en entornos enterprise.

Cypress llegó en 2017 con una propuesta diferente: olvidar el modelo de WebDriver y ejecutar los tests directamente en el navegador, junto a la aplicación. Eso lo hace más rápido en muchos escenarios y le da capacidades de debugging que Selenium no tiene. Está pensado para JavaScript y TypeScript.

Playwright lo publicó Microsoft en 2020. Aprendió de los problemas de Cypress, añadió soporte real para múltiples navegadores, múltiples tabs, contextos aislados y una API async/await que se comporta de forma predecible. En tres años ha pasado de ser el nuevo a ser la referencia para proyectos modernos.

El mismo test en los tres frameworks: cómo se ve la diferencia de sintaxis

La mejor forma de entender las diferencias no es leer descripciones, es ver el mismo test escrito en los tres. El test es un login básico: entrar a una web de ejemplo, rellenar usuario y contraseña, hacer clic en el botón y verificar que el usuario llega al dashboard.

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

test('login correcto', async ({ page }) => {
  await page.goto('https://app.ejemplo.com/login');

  await page
    .getByLabel('Email')
    .fill('usuario@ejemplo.com');

  await page
    .getByLabel('Contraseña')
    .fill('micontraseña123');

  await page
    .getByRole('button', { name: 'Entrar' })
    .click();

  await expect(page)
    .toHaveURL('/dashboard');

  await expect(
    page.getByText('Bienvenido')
  ).toBeVisible();
});

// cypress/e2e/login.cy.js

describe('Login', () => {
  it('login correcto', () => {
    cy.visit(
      'https://app.ejemplo.com/login'
    );

    cy.get('[data-cy="email"]')
      .type('usuario@ejemplo.com');

    cy.get('[data-cy="password"]')
      .type('micontraseña123');

    cy.get('[data-cy="submit"]')
      .click();

    cy.url()
      .should('include', '/dashboard');

    cy.contains('Bienvenido')
      .should('be.visible');
  });
});

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

def test_login_correcto():
    driver = webdriver.Chrome()
    wait = WebDriverWait(driver, 10)

    driver.get(
        'https://app.ejemplo.com/login'
    )

    wait.until(EC.presence_of_element_located(
        (By.ID, 'email')
    )).send_keys('usuario@ejemplo.com')

    driver.find_element(
        By.ID, 'password'
    ).send_keys('micontraseña123')

    driver.find_element(
        By.CSS_SELECTOR, 'button[type="submit"]'
    ).click()

    wait.until(EC.url_contains('/dashboard'))

    welcome = driver.find_element(
        By.XPATH,
        "//*[contains(text(),'Bienvenido')]"
    )
    assert welcome.is_displayed()

    driver.quit()

Fíjate en lo que revela esta comparativa. Playwright usa locators semánticos (getByLabel, getByRole) que son más robustos frente a cambios en el HTML. Cypress usa atributos data-cy que hay que añadir al código fuente. Selenium requiere gestionar los waits explícitamente y el código resulta más verboso, aunque más flexible.

Ninguno de los tres es incorrecto. Pero la diferencia en legibilidad es real, y en una suite grande de varios cientos de tests esa diferencia se acumula.

Playwright en profundidad: por qué lidera en proyectos nuevos

La razón principal por la que Playwright se ha impuesto en proyectos modernos no es la velocidad, aunque es más rápido que Selenium. Es la API consistente y el soporte multi-navegador sin configuración extra.

Con Playwright escribes un test una vez y lo ejecutas en Chromium, Firefox y WebKit (Safari) sin tocar nada. Para equipos que necesitan garantizar compatibilidad cross-browser, eso elimina semanas de configuración y mantenimiento.

Lo que hace bien Playwright

• Auto-waits: espera automáticamente a que los elementos sean accionables antes de interactuar con ellos. Menos flakiness, menos waitForSelector manuales.
• Contextos de navegador aislados: puedes correr tests en paralelo sin que interfieran entre sí, cada uno con su propia sesión, cookies y almacenamiento.
• Testing de múltiples tabs y frames: algo que Cypress no soporta bien y que en aplicaciones reales aparece constantemente.
• API requests dentro del test: puedes hacer llamadas a la API directamente desde el test para preparar el estado inicial sin necesidad de UI. Eso hace los tests más rápidos y más fiables.
• Soporte para TypeScript de serie: sin configuración adicional.
• Modo UI para debugging: un inspector visual que muestra qué hace el test paso a paso, con capturas de pantalla de cada acción.

Lo que no hace tan bien

• La curva de aprendizaje inicial es algo más pronunciada que Cypress para alguien que viene del mundo frontend puro.
• El modo interactivo no es tan fluido como el Test Runner de Cypress para desarrollo de tests en caliente.
• La comunidad es más reciente: hay menos respuestas en Stack Overflow para problemas muy específicos, aunque la documentación oficial compensa.

Cypress en profundidad: sólido, maduro, con sus límites

Cypress tiene algo que no tiene ningún otro framework: una experiencia de desarrollo (DX) difícil de igualar para proyectos web JavaScript. El Test Runner, la interfaz de time-travel debugging donde puedes ver cada paso del test con la aplicación tal como estaba en ese momento, es genuinamente útil cuando estás escribiendo y depurando tests.

Eso tiene un precio. Cypress ejecuta los tests dentro del navegador, lo que le da ese nivel de introspección, pero también le impone limitaciones estructurales que no va a poder superar sin cambiar su arquitectura.

Lo que hace bien Cypress

• DX de primer nivel: el Test Runner es el mejor de los tres para el ciclo de escribir-ejecutar-depurar tests durante el desarrollo.
• Curva de entrada suave: si ya sabes JavaScript, Cypress es el más rápido de aprender. La sintaxis encadenada es intuitiva.
• Comunidad madura: lleva más años que Playwright, hay más recursos, plugins y respuestas en la comunidad.
• Integración con Component Testing: puede testear componentes React, Vue o Angular de forma aislada, sin necesidad de montar la aplicación completa.

Los límites que debes conocer antes de elegirlo

• Sin soporte real para múltiples tabs: es la limitación más frecuente que tropieza en aplicaciones reales que abren nuevas ventanas.
• Cross-browser limitado: soporta Chrome, Edge y Firefox, pero no Safari/WebKit de forma nativa. Para testing iOS o Safari hay que hacer malabares.
• Solo JavaScript/TypeScript: si tu equipo trabaja en Python o Java, Cypress no es una opción.
• Lento en suites grandes: el paralelismo requiere Cypress Cloud (de pago). Playwright lo resuelve de serie.

Selenium en profundidad: el estándar que sigue vivo

Selenium no ha muerto. Es el framework con mayor presencia en empresas grandes, en proyectos enterprise y en equipos con QA de perfil tradicional. La razón es sencilla: lleva veinte años y tiene una masa de código, documentación, tutoriales y profesionales que ninguno de los otros dos puede igualar todavía.

El modelo de Selenium es diferente: el test se comunica con el navegador a través del protocolo WebDriver, que actúa como intermediario. Eso lo hace más lento que los otros dos en ejecución, y requiere más código boilerplate, pero también lo hace el más flexible en entornos complejos.

Cuándo Selenium sigue teniendo sentido

• Tienes una suite de cientos o miles de tests escrita en Java o Python que no puedes reescribir.
• Necesitas testear aplicaciones de escritorio o entornos con navegadores antiguos que los otros frameworks no soportan.
• El equipo ya lo conoce bien y el tiempo de migración no justifica el beneficio.
• Trabajas en consultoría y el cliente exige Selenium por contrato o estándares corporativos.
• Necesitas Python para la suite de automatización, quieres testing de API con pytest en el mismo stack y prefieres mantener consistencia de lenguaje.

Por qué no lo elegirías para un proyecto nuevo

• Configurar Selenium desde cero en 2026 es trabajo que en Playwright o Cypress se resuelve en minutos.
• Los waits explícitos son responsabilidad del desarrollador: la fuente número uno de tests frágiles en suites Selenium.
• El código es notablemente más verboso, lo que dificulta el mantenimiento a largo plazo.
• No tiene modo de debugging visual equiparable a los otros dos.

Comparativa directa: los números que importan

Cuál elegir según tu situación: el árbol de decisión

Deja de leer comparativas y responde a estas preguntas en orden. La primera que encaja es tu respuesta.

Cuál aprender para encontrar trabajo en España en 2026

Esta es la pregunta que más recibo. La respuesta ha cambiado en los últimos dos años.

Hasta 2023, Cypress era la respuesta clara para quien empezaba en automatización en España: era más fácil de aprender, tenía más comunidad en español y aparecía en más ofertas de startups y empresas de producto.

En 2025-2026 la balanza se ha inclinado. Las ofertas de QA Automation que piden Playwright han superado en número a las que piden Cypress exclusivamente. Muchas piden los dos, o piden "experiencia en frameworks modernos de automatización" sin especificar.

Lo que sí sigue siendo constante: Selenium aparece en perfiles más senior y en empresas más grandes, no en las posiciones de entrada en proyectos modernos.

Si quieres dar ese paso de forma estructurada, en 17lab tenemos dos cursos orientados exactamente a esto. El curso de introducción a la automatización te da la base para entender qué estás haciendo y por qué, sin quedarte en la superficie. Y el curso de automatización avanzada trabaja Playwright, Cypress y pytest en profundidad, con casos reales y el tipo de ejercicios que encuentras en un trabajo real.

Una nota sobre los snippets de código que has visto

Los tres tests que he mostrado arriba hacen lo mismo y, en condiciones normales, los tres pasarían. Pero hay matices que solo ves cuando llevas tiempo trabajando con cada uno.

El test de Playwright usa getByLabel y getByRole. Eso significa que si el desarrollador cambia el atributo id del campo, el test sigue funcionando siempre que el label o el rol no cambien. Es más resistente al cambio.

El test de Cypress usa data-cy. Es la práctica recomendada por Cypress porque desacopla el selector de la implementación, pero requiere coordinación con el equipo de desarrollo para añadir esos atributos al HTML. En equipos donde el QA y el dev están bien coordinados, funciona muy bien. En equipos donde el QA trabaja sobre código que no controla, puede ser un problema.

El test de Selenium usa IDs y selectores CSS. Más frágil por defecto, pero el más familiar para quien viene de otros contextos web.

La pregunta que nadie hace pero debería: ¿y el mantenimiento?

Elegir un framework no es solo una decisión de hoy. Es una decisión sobre qué va a ser fácil y qué va a ser difícil dentro de seis meses, cuando la aplicación haya cambiado y la suite tenga doscientos tests.

Los tests frágiles son el mayor problema en automatización. Un test que falla cuando no debería, o que pasa cuando no debería, destruye la confianza del equipo en la suite y termina en que nadie le hace caso.

Los auto-waits de Playwright y Cypress reducen drásticamente la fragilidad respecto a Selenium. Los locators semánticos de Playwright (basados en roles y labels accesibles) son más estables que los selectores CSS o XPath. Estos detalles pequeños se acumulan.