Selenium vs Playwright: Cuál Elegir en 2026

TL;DR

• Playwright: Moderno, 2-3x más rápido, auto-waiting, Trace Viewer, respaldado por Microsoft
• Selenium: Veterano de 20 años, ecosistema más grande, más lenguajes, probado en enterprise
• Velocidad: Playwright gana — protocolos nativos del navegador vs WebDriver basado en HTTP
• Estabilidad: Auto-waiting de Playwright reduce tests flaky de ~8% a ~1%
• Elige Playwright para: proyectos nuevos, apps web modernas, equipos TypeScript/Python, velocidad CI/CD
• Elige Selenium para: navegadores legacy, infraestructura Grid existente, móvil via Appium, Ruby/Kotlin

Mi opinión: Para cualquier proyecto nuevo en 2026, empezaría con Playwright. Selenium tiene sentido solo con restricciones específicas — navegadores legacy, Appium, o un test suite existente grande.

Tiempo de lectura: 15 minutos

Selenium dominó la automatización de testing web por dos décadas, acumulando más de 31.000 estrellas en GitHub y convirtiéndose en el estándar W3C WebDriver. Playwright llegó en 2020 — construido por ex-ingenieros de Puppeteer en Microsoft — y desde entonces ha crecido hasta más de 95.000 estrellas en GitHub, siendo uno de los proyectos de testing de mayor crecimiento en la historia. Según la encuesta JetBrains Developer Ecosystem 2025, la adopción de Playwright entre testers profesionales aumenta significativamente año tras año mientras Selenium mantiene su fortaleza en entornos enterprise. La arquitectura de Playwright se comunica con los browsers mediante protocolos de depuración nativos sobre conexiones WebSocket persistentes, eliminando el overhead HTTP por acción que hace a Selenium más lento y propenso a flakiness. Según la documentación de Selenium, el estándar W3C WebDriver garantiza compatibilidad cross-browser y portabilidad entre lenguajes, ventajas que siguen importando en contextos enterprise específicos. La elección correcta depende de tus restricciones: soporte de navegadores legacy, infraestructura existente y si el costo de migración está justificado.

He liderado migraciones de Selenium a Playwright en dos equipos diferentes. Una migración nos ahorró 40 minutos por pipeline CI. La otra no valió la pena — necesitábamos integración con Appium que Playwright no soporta. Esta comparación viene de esa experiencia.

Arquitectura: Por Qué Importa #

La diferencia arquitectónica entre Selenium y Playwright explica casi todas las demás diferencias — velocidad, estabilidad, debugging y diseño de API.

Selenium: Protocolo WebDriver #

Selenium usa el protocolo W3C WebDriver, basado en HTTP:

Código Test → HTTP Request → WebDriver Server → Driver Navegador → Navegador
     ↑                                                                |
     └──────────────────── HTTP Response ←───────────────────────────┘

Cada acción es un round-trip HTTP. ¿Click en botón? HTTP request. ¿Leer texto? HTTP request. ¿Verificar elemento? HTTP request. Cada uno toma 1-5ms de overhead de red, y se acumula rápidamente en miles de operaciones.

También necesitas ejecutables de driver separados — ChromeDriver para Chrome, GeckoDriver para Firefox. Desajustes de versión entre navegador y driver son causa frecuente de fallas en CI.

Playwright: Protocolos Nativos del Navegador #

Playwright se comunica con navegadores a través de sus protocolos nativos de debugging:

Código Test → Playwright → Navegador (conexión WebSocket persistente)

Una conexión WebSocket permanece abierta durante todo el test. Todos los comandos fluyen por ella — sin overhead HTTP por acción. Playwright también maneja los binarios de navegador, así que no ocurren desajustes de versión.

Qué permiten los protocolos nativos:

• Interceptar requests de red sin configuración de proxy
• Capturar logs de consola, excepciones y métricas de performance automáticamente
• Emular dispositivos, geolocalización, permisos y esquemas de color
• Tomar screenshots durante acciones, no solo en puntos de assertion

Comparación de Features #

Benchmarks de Velocidad #

Mismo test suite: login, operaciones CRUD, búsqueda, validaciones de formularios, checkout. Entorno: GitHub Actions, Ubuntu runner, Chrome/Chromium.

Ejecución Secuencial (100 tests) #

Playwright es 2.7x más rápido secuencialmente. La diferencia viene de tres fuentes: sin overhead HTTP por acción, auto-waiting incorporado (sin retry loops), y lanzamiento de navegador más rápido con persistent contexts.

Ejecución Paralela (100 tests, 4 workers) #

Los browser contexts de Playwright son más livianos que instancias completas de navegador. Puedes correr 10+ workers paralelos en un solo CI runner sin problemas de memoria.

Developer Experience #

Playwright: Moderno y Conciso #

// Test de login — Playwright (TypeScript)
import { test, expect } from '@playwright/test';

test('login with valid credentials', async ({ page }) => {
  await page.goto('/login');
  await page.getByTestId('email').fill('user@example.com');
  await page.getByTestId('password').fill('P@ssw0rd!');
  await page.getByTestId('submit').click();

  // Automáticamente espera navegación y elemento
  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByTestId('welcome')).toContainText('Welcome');
});

Qué destaca:

• Sin waits explícitos — cada fill(), click(), expect() auto-espera
• Locator API — getByTestId(), getByRole(), getByText() son legibles y resilientes
• Web-first assertions — toHaveURL(), toContainText() auto-reintentan hasta pasar
• Aislamiento de tests — cada test recibe un browser context fresco por defecto

// Mock de red — incorporado
await page.route('**/api/login', route =>
  route.fulfill({
    status: 200,
    body: JSON.stringify({ token: 'fake-jwt' }),
  })
);

Selenium: Verboso pero Universal #

// Test de login — Selenium (Java)
@Test
public void loginWithValidCredentials() {
    driver.get(baseUrl + "/login");

    WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));

    wait.until(ExpectedConditions.presenceOfElementLocated(By.id("email")))
        .sendKeys("user@example.com");

    driver.findElement(By.id("password")).sendKeys("P@ssw0rd!");

    wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")))
        .click();

    wait.until(ExpectedConditions.urlContains("/dashboard"));

    String welcomeText = wait.until(
        ExpectedConditions.visibilityOfElementLocated(By.id("welcome"))
    ).getText();

    assertTrue(welcomeText.contains("Welcome"));
}

Cada interacción necesita waits explícitos. El patrón WebDriverWait + ExpectedConditions es boilerplate que escribes cientos de veces. Pero obtienes:

• Cualquier lenguaje — Java, Python, C#, Ruby, Kotlin y más
• Cualquier navegador — incluyendo Safari, IE11 y móviles via Appium
• 20 años de ecosistema — cada pregunta ya fue hecha y respondida en Stack Overflow
• Confianza enterprise — revisado en seguridad y aprobado en la mayoría de organizaciones grandes

Debugging: Donde Playwright Domina #

Esta es probablemente la diferencia práctica más grande entre los frameworks.

Playwright Trace Viewer #

Cuando un test falla, Playwright puede grabar un trace — una cronología completa de todo lo que pasó:

# Correr tests con tracing
npx playwright test --trace on

# O solo en falla (recomendado)
npx playwright test --trace retain-on-failure

El Trace Viewer muestra:

1. Timeline — cada acción con timestamps
2. DOM snapshots — el estado exacto de la página en cada paso
3. Network log — cada request/response con timing
4. Console output — todos los console.log, warnings, errores
5. Screenshots — antes y después de cada acción

Puedes recorrer un test fallido como un video, viendo exactamente cómo se veía la página en cada momento. No más “funciona en mi máquina” — el trace captura todo.

Extensión VS Code de Playwright #

La extensión oficial de VS Code agrega:

• Debugging en vivo — corre tests con breakpoints, inspecciona estado de página
• Pick locator — pasa cursor sobre elementos para generar código de locator
• Watch mode — tests se re-ejecutan al guardar archivo
• Test explorer — árbol visual de tests con botones run/debug

Debugging en Selenium #

El workflow de debugging de Selenium es más manual:

1. Screenshots — configuras TakesScreenshot en un hook teardown
2. Logs — driver.manage().logs().get("browser") para output de consola
3. Stack traces — debugging estándar de lenguaje
4. Video — requiere herramientas externas (Allure, Selenoid, etc.)

Cuando un test de Selenium falla en CI, típicamente obtienes un stack trace y quizás un screenshot. Entender por qué falló requiere agregar más instrumentación y re-correr.

Comparación de Costos #

La diferencia de costo más grande es tiempo de CI. Si pagas por minuto en GitHub Actions, la ventaja de velocidad de Playwright se traduce directamente en facturas más bajas.

Cuándo Elegir Selenium #

1. Soporte navegadores legacy — IE11 o versiones antiguas todavía en uso
2. Integración Appium — testing móvil nativo (iOS, Android) es crítico
3. Equipos Ruby o Kotlin — Playwright no soporta estos lenguajes
4. Infraestructura Grid existente — inversión grande en Selenium Grid
5. Mandatos enterprise — estándares corporativos requieren Selenium específicamente
6. Test suite existente grande — 5000+ tests Selenium hacen migración impráctica

Cuándo Elegir Playwright #

1. Proyectos nuevos — sin restricciones legacy, empieza con la mejor herramienta
2. Apps web modernas — SPAs, WebSocket, Server-Sent Events, Web Workers
3. Velocidad CI/CD — 2-3x más rápido reduce directamente tiempos de pipeline
4. Equipos TypeScript/Python — soporte first-class con excelente DX
5. Problemas de tests flaky — auto-waiting elimina la causa #1 de inestabilidad
6. Cross-browser en cualquier OS — testear WebKit/Safari en Linux/Windows
7. Testing API + UI — contexto request incorporado para API calls sin navegador

Estrategia de Migración: Selenium → Playwright #

“Recomiendo migrar de Selenium a Playwright cuando la tasa de tests flaky en CI supera el 5% o tu test suite tarda más de 15 minutos en ejecución secuencial. Si estás por debajo de esos umbrales y Selenium es estable, el costo de migración no está justificado a menos que necesites específicamente testing WebKit cross-browser o desarrollo TypeScript-first. Empieza con tests nuevos en Playwright y migra los antiguos de forma oportunista durante el refactoring — no como proyecto dedicado.” — Yuri Kan, Senior QA Lead

Fase 1: Evaluación (1-2 semanas) #

• Auditar tu test suite existente de Selenium (contar tests, categorizar por tipo)
• Identificar features específicos de Selenium que usas (Grid, Appium, lenguajes)
• Estimar esfuerzo: 1-3 horas por test para conversión manual
• Decidir migración gradual vs. completa

Fase 2: Piloto (2-4 semanas) #

• Configurar Playwright junto a Selenium
• Migrar 10-20 tests representativos
• Medir mejoras de velocidad y estabilidad
• Identificar patrones para conversión masiva

Fase 3: Migración Gradual #

• Escribir todos los tests nuevos en Playwright
• Migrar tests existentes durante ciclos de refactoring
• Priorizar tests flaky y lentos primero
• Mantener Selenium para tests no-migrables

Patrones Comunes de Conversión #

// Selenium (Java)
driver.findElement(By.cssSelector(".btn")).click();
driver.findElement(By.id("input")).sendKeys("text");
String text = driver.findElement(By.className("result")).getText();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("modal")));

// Playwright (TypeScript) — equivalente
await page.locator('.btn').click();
await page.locator('#input').fill('text');
const text = await page.locator('.result').textContent();
// No se necesita wait explícito — acciones de locator auto-esperan
await expect(page.locator('#modal')).toBeVisible();

AI en Migración #

Las herramientas de AI pueden acelerar significativamente la migración Selenium → Playwright.

Qué hace bien la AI:

• Convertir locators y acciones de Selenium a sintaxis Playwright
• Traducir Page Objects entre frameworks
• Generar código idiomático de Playwright desde patrones Selenium
• Identificar patrones deprecated y sugerir alternativas modernas
• Escribir archivos de config Playwright basados en setup de Selenium Grid

Qué todavía necesita humanos:

• Evaluar si la migración vale la inversión
• Manejar extensiones y plugins custom de Selenium
• Diseñar timeline de migración y entrenamiento del equipo
• Gestionar transición de infraestructura (Grid → paralelo nativo)

Prompt útil:

“Convierte este test de Selenium [Java/Python] a Playwright [TypeScript/Python]. Usa locators modernos de Playwright (getByTestId, getByRole) en lugar de selectores CSS. Elimina todos los waits explícitos — Playwright auto-espera. Agrega web-first assertions (toBeVisible, toHaveText). Mantén la misma lógica de test.”

FAQ #

¿Es Playwright mejor que Selenium? #

Para la mayoría del testing web moderno en 2026, sí. Playwright tiene auto-waiting incorporado que virtualmente elimina tests flaky, ejecución 2-3x más rápida a través de protocolos nativos del navegador, y debugging superior con Trace Viewer. Sin embargo, Selenium sigue siendo mejor para equipos que necesitan soporte de navegadores legacy (IE11), testing móvil nativo via Appium, o soporte para lenguajes como Ruby y Kotlin. Yo elegiría Playwright para cualquier proyecto nuevo a menos que tuviera una restricción específica requiriendo Selenium.

¿Debería migrar de Selenium a Playwright? #

Migra si estás gastando tiempo significativo investigando tests flaky, tus pipelines CI son lentos, o estás empezando a testear features web modernos (WebSocket, Service Workers) que Selenium maneja mal. No migres si tienes 5000+ tests estables de Selenium, dependes de Appium para móvil, o tu equipo principalmente usa Ruby/Kotlin. El esfuerzo típicamente es 1-3 horas por test. Considera un enfoque gradual — tests nuevos en Playwright, tests existentes se quedan en Selenium.

¿Playwright está reemplazando a Selenium? #

En términos de adopción en proyectos nuevos, en gran medida sí. La mayoría de equipos comenzando de cero en 2026 eligen Playwright. Pero Selenium no está desapareciendo — sigue siendo el estándar en muchas empresas, tiene el ecosistema más grande, y es la única opción para algunos casos de uso (Appium móvil, IE11, Ruby). Piénsalo como jQuery vs React: la herramienta antigua sigue ampliamente usada aunque la nueva se convierta en el default.

¿Pueden Playwright y Selenium trabajar juntos? #

Sí. El patrón más práctico: escribe tests nuevos en Playwright, mantén tests existentes de Selenium corriendo hasta que se migren o retiren. Ambos pueden correr en el mismo pipeline CI apuntando a la misma aplicación. El costo es mantener dos conjuntos de dependencias, dos configs de test, y dos patrones diferentes. Recomiendo esto solo como puente de migración, no como arquitectura permanente.

¿Es Playwright más rápido que Selenium? #

Sí, consistentemente 2-3x más rápido. Tres razones: Playwright usa conexiones WebSocket persistentes en lugar de requests HTTP por acción, auto-waiting elimina overhead de sleep/retry, y browser contexts son más livianos que instancias completas de navegador para ejecución paralela. En mis benchmarks, 100 tests tomaron 4 minutos en Playwright vs 11.5 minutos en Selenium en el mismo CI runner.

¿Cuál tiene mejores herramientas de debugging? #

Playwright, y con gran diferencia. Trace Viewer te da una cronología completa con snapshots DOM, logs de red, y output de consola para cada test fallido — como una grabación de video de lo que pasó. La extensión VS Code agrega debugging en vivo con breakpoints. Selenium te da un stack trace y (si está configurado) un screenshot. Debuggear un test flaky de Selenium puede tomar horas; con traces de Playwright, usualmente toma minutos.

Fuentes: La documentación de Selenium WebDriver cubre el protocolo W3C WebDriver, compatibilidad de navegadores y guías de configuración. La documentación de Playwright proporciona la referencia completa de API, configuración de browsers y mejores prácticas para testing web moderno.

Ver También #

• Selenium Tutorial para Principiantes - Guía completa de Selenium desde cero
• Playwright Tutorial - Testing web moderno con Playwright
• Playwright: Guía Comprensiva - Patrones avanzados y arquitectura de Playwright
• Selenium WebDriver en 2026 - ¿Todavía vale la pena aprender Selenium?
• Selenium Grid 4 - Testing distribuido con Selenium Grid
• Playwright vs Cypress - Herramientas modernas cara a cara
• Cypress vs Selenium - La comparación clásica
• Test Automation Tutorial - Fundamentos y estrategia de automatización