WebDriver BiDi: el estándar que viene

Lo que WebDriver clásico no puede

WebDriver funciona como una conversación de una sola vía: tu test manda una orden ("haz clic", "dame el texto") y espera la respuesta. Lo que pasa en el navegador entre una orden y otra —un error de JavaScript, una llamada de red que falla, un mensaje en la consola— no lo ve.

Durante años, la forma de ver eso fue el Chrome DevTools Protocol (CDP): potente, pero propio de Chrome y sin garantía de estabilidad entre versiones.

Qué es WebDriver BiDi

WebDriver BiDi es un protocolo estándar del W3C, creado por el proyecto Selenium junto con los fabricantes de navegadores. Agrega un canal bidireccional (un WebSocket) a WebDriver: además de mandar órdenes, el test puede escuchar eventos del navegador.

En la práctica, eso permite que una prueba:

• capture los errores de JavaScript y los mensajes de consola mientras recorre la app;
• observe o intercepte las llamadas de red;
• reaccione a eventos en vez de esperar a ciegas.

Es lo que CDP hacía en Chrome, pero estándar y multi-navegador.

En qué estado está (al cierre de 2026)

• El estándar es un Working Draft del W3C, con versión del 16 de septiembre de 2026.
• Chrome, Firefox y Edge lo soportan. Safari todavía no; Selenium 4.47 agregó soporte para Safari Technology Preview.
• Selenium 4.49 salió el 9 de septiembre de 2026. Las versiones 4.46 a 4.49 trabajaron sobre todo en unificar la capa BiDi entre lenguajes a partir de un esquema común, con errores tipados.

La API de BiDi varía según el lenguaje y todavía se está unificando. Antes de escribir código, revisa la sección de BiDi de la documentación oficial de Selenium para Python: es la fuente que se mantiene al día.

Qué cambia en tus tests

Un uso que vale la pena desde ya: fallar el test si aparece un error de JavaScript durante un flujo, aunque la pantalla se vea bien. Muchos bugs reales no se ven en la UI: quedan en la consola. Con BiDi, el test puede escucharlos y reportarlos con evidencia, en Chrome, Firefox y Edge.

Dónde queda la IA

Selenium no publica una capa de IA propia equivalente a los agentes de Playwright o a cy.prompt. Publica un archivo /llms.txt para que los agentes indexen su documentación, y los servidores MCP para Selenium que circulan son de la comunidad, no oficiales: si usas uno, revísalo como cualquier dependencia de terceros.

Eso no lo deja atrás, lo pone en otro lugar: Selenium aporta el estándar y el alcance (cinco lenguajes, cualquier navegador con driver, Grid para escalar), y la IA la pone un agente de código externo que lee tu repo.

¿Sigue siendo la opción correcta en 2027?

Para muchos equipos, sí. Si tu suite vive en Java, C# o Ruby, o necesitas un Grid propio con muchas máquinas, Selenium sigue siendo la respuesta. Y si BiDi completa su camino y Safari se suma, la ventaja técnica de controlar el navegador se empareja entre las tres herramientas, y la competencia pasa a jugarse en agentes, reportes y datos de CI.

Cierre del curso

Recorriste el arco completo: primer script, selectores y esperas profesionales, POM, paralelo y CI, datos deterministas, infraestructura escalable y el estándar que viene con BiDi. Es el stack que piden los roles de QA Automation con Selenium.

Siguientes pasos naturales: Playwright pro para sumar el framework moderno, o QA con IA para escribir y mantener todo esto más rápido.

Cierra el curso con el quiz y documenta tu decisión sobre Selenium para 2027 en el reto final.