WebDriver vs CDP: qué puede hacer cada conexión

La elección entre WebDriver y CDP se concreta cuando una prueba necesita un comando o evento específico. BotBrowser proporciona integraciones documentadas de automatización, pero no puede añadir operaciones ausentes del cliente ni elegir la conexión de la suite.

TL;DR

WebDriver, WebDriver BiDi y Chrome DevTools Protocol (CDP) son contratos de protocolo distintos, no tres nombres para la misma función. Elige según la operación necesaria y verifica que el navegador, el driver, la biblioteca y el modo de conexión la admitan. Selenium puede exponer WebDriver clásico, BiDi y CDP; el nombre de la biblioteca no identifica el protocolo activo.

Contenido

• Una biblioteca no es un protocolo
• Mapa de capacidades
• Elegir según la operación
• Verificar la conexión real
• El núcleo del navegador queda por debajo
• Conclusión práctica

Una biblioteca no es un protocolo

La expresión «WebDriver vs CDP» parece una elección binaria, pero mezcla varias decisiones. WebDriver es un estándar del W3C para controlar un agente de usuario mediante un extremo remoto. WebDriver BiDi es otro protocolo del W3C para comandos y eventos bidireccionales. CDP es el protocolo DevTools de Chromium, con dominios para el navegador y JavaScript. La biblioteca es una capa distinta: puede exponer uno o varios protocolos, o una conexión propia del framework.

La pregunta útil no es «¿qué protocolo puede ver más?», sino «¿qué conexión compatible ofrece la operación que necesita esta prueba, con el comportamiento y la portabilidad requeridos?». Una prueba que pulsa un botón y espera un encabezado quizá solo necesite comandos estándar de WebDriver. Una prueba que registra eventos de red puede necesitar BiDi o una ruta CDP específica del navegador. Ninguna observación convierte una opción en superior para todos los casos.

Selenium documenta su API clásica de WebDriver, las API de BiDi y ejemplos de CDP. Su página sobre compatibilidad con CDP describe esa compatibilidad como temporal hasta que se implemente WebDriver BiDi. Playwright ofrece su conexión de protocolo nativa y otra conexión CDP para Chromium, que su documentación califica como de menor fidelidad. Por eso «uso Selenium» o «uso Playwright» no basta para saber qué protocolo está activo. Para suscripciones y ciclo de vida de eventos, consulta el flujo de trabajo de eventos WebDriver BiDi; una migración de framework tiene otro alcance, descrito en el inventario de migración desde Selenium.

Mapa de capacidades

La tabla describe formas definidas por los protocolos, no garantiza que cada navegador o cliente implemente todas las operaciones. «Puede expresar» significa que el esquema define comandos o eventos relacionados; verifica la implementación y la versión que vas a usar.

Tarea	WebDriver clásico	WebDriver BiDi	CDP	Qué verificar
Buscar elementos, pulsar, escribir y navegar	Modelo estándar de comandos para elementos y contextos	Hay comandos para contextos, pero el soporte del cliente varía	Los dominios Page y DOM ofrecen controles de Chromium	Semántica de localizadores, contexto y comandos disponibles
Leer la consola	No es el flujo principal de comandos/respuestas clásico	El módulo log define informes de eventos	Runtime y Log exponen eventos de consola	Evento habilitado, contexto y retención de argumentos
Observar tráfico de red	No ofrece un flujo universal de eventos en el WebDriver clásico	El módulo network define eventos de solicitud y respuesta	Network.enable activa el seguimiento y sus eventos	Cobertura, política del cuerpo, redacción y soporte del stack
Evaluar JavaScript de la página	La ejecución de scripts forma parte de sus comandos	Define operaciones de script para realms y contextos	Runtime.evaluate evalúa una expresión en el objeto global	Realm, permisos, CSP y serialización del valor
Cambiar user-agent o métricas del dispositivo	Las capacidades u opciones del navegador pueden configurar la sesión, no son una anulación en vivo universal	No promete que todos los navegadores tengan la misma anulación	CDP incluye Network.setUserAgentOverride y anulación de métricas	Coherencia de metadatos y diferencias fuera de la anulación
Cambiar un permiso	Puede depender de capacidades u opciones específicas del navegador	Depende del comando disponible y su implementación	CDP tiene Browser.setPermission, marcado experimental	Permiso, origen, contexto y estado experimental

Esto es un mapa para investigar, no una puntuación. La ventaja de WebDriver clásico es una superficie estandarizada que pretende funcionar entre implementaciones. BiDi añade un modelo de eventos bidireccional especificado. CDP ofrece dominios orientados a Chromium que pueden ayudar con depuración y controles del navegador; que una biblioteca los facilite no los convierte en garantías multiplataforma.

Los protocolos también difieren en estabilidad. Un comando puede ser experimental, opcional, no estar implementado en cierto navegador o exponerse de otra forma en un driver antiguo. Incluso un inicio de sesión correcto solo demuestra que se creó una sesión, no que todos los comandos y eventos posteriores funcionen. El ejemplo de permisos se marca como experimental; el seguimiento de red requiere habilitar el dominio antes de esperar eventos.

Elegir según la operación

Empieza por inventariar operaciones, no por elegir un protocolo favorito. Anota la evidencia que necesita la prueba, no solo el método disponible en la biblioteca actual.

«Necesitamos más visibilidad» no basta. Nombra el dato que falta: una entrada de consola, el estado de una respuesta, un permiso, las dimensiones de la ventana o una afirmación visible para el usuario. Después define la condición mínima que probaría que la prueba lo obtuvo. Así se evita adoptar un protocolo de menor nivel solo porque su lista de dominios parece más larga. Una superficie amplia solo sirve si el comando existe en el entorno real y su salida responde a la pregunta de la prueba.

Necesidad	Primera ruta que evaluar	Condición
Navegación e interacción portables	WebDriver clásico o conexión nativa documentada del framework	Confirma navegadores admitidos y semántica de comandos
Recibir eventos mientras continúan los comandos	WebDriver BiDi	Confirma módulo, ámbito de suscripción e implementación del driver
Inspeccionar red de Chromium o usar una operación de emulación propia	CDP	Fija Chromium y el cliente; trátalo como específico de Chromium
Migrar una suite Selenium sin cambiar de framework	Mantén WebDriver primero; añade BiDi o CDP solo para una carencia concreta	Un cambio de protocolo puede cambiar eventos y depuración
Ejecutar la misma suite en varios motores	Prefiere rutas estándar si cubren la necesidad	Un extremo CDP de Chromium no demuestra equivalencia en Firefox o WebKit

Por ejemplo, una prueba puede necesitar afirmar que se muestra una página de confirmación y conservar el estado de la solicitud fallida. La afirmación visible pertenece al flujo de la página. El evento de red ayuda a diagnosticar el fallo, pero observar una respuesta no prueba que la aplicación haya mostrado éxito. BiDi o CDP deben aportar evidencia diagnóstica sin sustituir la afirmación semántica. Si solo importa Chromium, CDP puede ofrecer una operación que el driver elegido aún no exponga mediante BiDi; registra esa dependencia en vez de llamar a la suite independiente del protocolo.

La misma separación se aplica a JavaScript. WebDriver ofrece ejecución de scripts, BiDi define realms y evaluación, y CDP proporciona Runtime.evaluate. Eso no implica que el realm, la serialización, el ciclo de vida o los errores sean idénticos. Si una afirmación depende de una variable global, indica qué contexto o realm la contiene y comprueba cómo devuelve el valor el cliente.

Para los resultados de scripts, registra si el código se ejecuta en el documento principal, un frame secundario o un mundo aislado. Una expresión correcta en el frame equivocado puede producir un dato plausible pero irrelevante. Distingue también una excepción de página, un fallo del transporte y un problema de serialización del cliente. El texto JavaScript puede comportarse de forma distinta si la página navega entre el envío del comando y la respuesta. Vincula el resultado a un identificador de contexto o realm si el protocolo lo expone, y falla con claridad si el contexto desaparece.

No confundas «se puede cambiar» con «se vuelve equivalente». La anulación de métricas cambia ciertos valores de pantalla y viewport, pero no recrea la ruta gráfica física, las fuentes instaladas, el hardware de entrada ni todas las capacidades multimedia. La anulación de user-agent tampoco alinea automáticamente client hints y todas las superficies del documento. Indica qué superficie se midió y qué diferencias quedan.

La matriz también debe registrar el coste de portabilidad. Si solo se ejecuta en Chromium, una dependencia de CDP puede ser una decisión explícita y válida. Si la afirmación debe funcionar en varios motores, comprueba primero si bastan las operaciones estándar de WebDriver o BiDi. No dupliques pruebas en dos protocolos a menos que esa observación detecte una regresión real; de otro modo la suite gana mantenimiento, no evidencia.

Si una operación no tiene una ruta equivalente en otro navegador, marca esa celda como no compatible o sin verificar, en lugar de cambiar silenciosamente el significado de la prueba. Una alternativa puede ser válida si observa el mismo resultado para el usuario, pero no es equivalente por devolver un campo con nombre parecido. Un evento de consola y un mensaje de error visible son evidencias diferentes. Anota juntos el resultado, el método de captura y las reglas de alternativa.

Verificar la conexión real

Antes de añadir una operación específica del protocolo, registra cuatro datos: navegador y versión, driver o extremo remoto, biblioteca cliente y versión, y método de conexión. «Selenium con Chrome» no basta. «Selenium 4, Chrome fijado, ChromeDriver local y WebDriver BiDi habilitado para network.responseCompleted» sí se puede comprobar. Si usas CDP, registra también si la biblioteca inició el navegador o se conectó a un extremo existente.

Guarda este registro junto a la configuración de prueba, no solo en un manual. Una actualización de paquete puede cambiar el extremo o los valores por defecto sin modificar el código de la prueba. En CI, imprime la versión efectiva del navegador y el modo elegido al crear la sesión. Para un navegador remoto, conserva las capacidades anunciadas y las opciones aceptadas. Configurar una opción no prueba que el extremo remoto la aplicara; la respuesta de sesión o una observación directa deben confirmar el comportamiento efectivo.

Haz una comprobación pequeña antes del flujo completo:

1. Crea una sesión nueva con la ruta exacta que se ejecuta en CI.
2. Envía el comando mínimo o la suscripción al evento necesario.
3. Registra capacidades negociadas, resultado y errores de operación no admitida.
4. Genera una solicitud o mensaje de consola en un fixture propio y verifica el evento y su contexto.
5. Cierra la sesión y confirma la limpieza de listeners, procesos y estado del fixture.

No deduzcas soporte solo de la página del protocolo. La definición responde si el método o evento existe en ese esquema. El navegador, el driver, el servicio remoto y el cliente determinan si funciona en tu ejecución. Fija la versión o referencia del esquema cuando necesites repetibilidad; la vista tot de CDP y el JSON en master cambian con el tiempo.

Mantén la salida del comando separada de la afirmación que respalda:

browser=Chrome <pinned version>
client=Selenium <pinned version>
connection=WebDriver BiDi
operation=subscribe to network.responseCompleted
result=subscription acknowledged; one fixture response observed
scope=owned local fixture, one browsing context
not established=all browsers support this event identically

Sustituye los marcadores con el entorno real antes de tratarlo como evidencia. Si falla la suscripción, es un resultado de soporte para ese stack, no una prueba de que BiDi no tenga la función. Si llega el evento pero falla la afirmación de página, conserva ambos resultados por separado. Una traza explica una prueba; no decide si el flujo del producto tuvo éxito.

Repite la comprobación cambiando un componente cada vez. Mantén el navegador y cambia el cliente o el driver; luego restaura el cliente y cambia la versión del navegador. Así puedes atribuir qué parte del stack modificó el soporte. Si también cambia el servicio remoto, pueden variar a la vez el binario, el salto de red, el dueño de la sesión y el puente del protocolo. Un registro de cambios pequeño aporta más que «funciona en mi máquina».

En pruebas por eventos, limita la captura a los tipos y contextos necesarios, fija un máximo de registros y elimina listeners al terminar. Los datos de consola y red pueden contener URL, cabeceras, texto de página o datos personales. El protocolo no define la política de retención. Redacta los valores sensibles antes de guardar artefactos y conserva solo los metadatos necesarios para relacionar el evento con el paso de prueba.

Para una prueba de comandos, registra el nombre del comando, la categoría de la respuesta y el estado posterior de la página. El acuse del comando solo indica que el extremo lo aceptó; no demuestra que la página alcanzara el resultado esperado. Espera una condición semántica, como que aparezca la región de confirmación, y conserva los detalles del protocolo como diagnóstico. Distingue el timeout sin respuesta del protocolo del timeout sin resultado de página.

El núcleo del navegador queda por debajo

Los protocolos exponen operaciones y observaciones, pero no definen todos los valores producidos por el motor. Una evaluación puede leer el DOM y un evento puede informar de una solicitud; el resultado del renderizado aún depende de fuentes, ruta gráfica, versión, sistema operativo y perfil. Un valor emulado tampoco modifica necesariamente todas las superficies relacionadas. La capa del protocolo y el núcleo del navegador responden preguntas distintas.

BotBrowser documenta valores del navegador e integraciones de automatización, pero no traduce comandos WebDriver a CDP, implementa un evento BiDi ausente en un cliente ni certifica paridad entre modos. El navegador puede mantenerse fijo mientras se evalúa una conexión compatible; el equipo aún debe verificar su cliente y operación exactos. La referencia de consistencia de automatización describe el límite del navegador, no una matriz de conformidad de protocolos. Si un comportamiento cambia, clasifica primero si procede del comando, del soporte del protocolo, de la traducción del cliente o del entorno del navegador.

No conviertas la comparación en un veredicto de identidad. Observar un valor desde JavaScript o cambiarlo mediante un comando no establece qué inferirá otro sistema de una sesión completa. Tampoco prueba que el mismo comando exista en otro motor. Limita la conclusión al navegador, conexión, operación y fixture registrados.

El protocolo es solo una parte del entorno. El cliente puede añadir valores por defecto, el driver traducir llamadas, un extremo remoto mediar la sesión y el núcleo producir los valores renderizados. Ante un dato inesperado, localiza la pregunta: ¿se envió la operación prevista?, ¿el extremo la aceptó?, ¿el cliente devolvió el resultado correctamente?, ¿el navegador produjo el estado esperado? La secuencia no presupone cuál capa falló; evita que la etiqueta del protocolo suplante la evidencia.

La misma cautela se aplica a comparaciones: si dos rutas devuelven el mismo valor DOM, solo se observó igualdad para ese valor y esa ejecución. No demuestra equivalencia en orden de eventos, errores, tiempos ni operaciones no compatibles. Si se requiere equivalencia, enumera las operaciones y compara cada resultado bajo condiciones controladas. Si basta una prueba fiable, elige la ruta compatible más acotada y afirma el resultado visible.

Preguntas frecuentes

¿CDP es lo mismo que WebDriver?

No. CDP es el protocolo DevTools de Chromium. WebDriver es un estándar del W3C y WebDriver BiDi tiene otra especificación bidireccional. Una biblioteca puede exponer varias rutas, por lo que debes comprobar el modo de conexión en vez de inferirlo del paquete.

¿Selenium solo usa WebDriver?

No. Su API principal es WebDriver, y Selenium también documenta BiDi y CDP. Su documentación describe CDP como temporal mientras avanza la implementación de BiDi. La disponibilidad depende de las versiones concretas de Selenium, navegador y driver.

¿CDP es siempre la mejor opción?

No se puede concluir eso. CDP tiene dominios específicos de Chromium útiles para algunas pruebas, mientras que WebDriver y BiDi aportan contratos estandarizados. Compara la operación exacta, el soporte del stack fijado y el coste de portabilidad.

¿La emulación hace que Chrome headless sea igual a un teléfono?

No. Un comando puede modificar las métricas indicadas, pero no recrea todos los sensores, fuentes, GPU, códecs, dispositivos de entrada o comportamiento del sistema operativo. Separa los campos emulados del entorno no modelado.

¿Puedo confiar en una operación que aparece en el esquema?

No sin comprobar la implementación. El esquema prueba que el protocolo define un método, no que una versión del navegador, driver, servicio o cliente lo implemente. Haz una comprobación acotada en el mismo modo que usa CI.

Fuentes

• WebDriver del W3C
• WebDriver BiDi del W3C
• Visor de Chrome DevTools Protocol
• Dominio Network de CDP
• Dominio Runtime de CDP
• Compatibilidad CDP de Selenium
• connectOverCDP de Playwright
• Consistencia de automatización BotBrowser

Conclusión práctica

Elige la conexión a partir de la operación: nombra el comando o evento, confirma el soporte del navegador, cliente y driver, registra versión y modo, y conserva una afirmación semántica para el resultado visible. Usa WebDriver para las interacciones estándar, BiDi cuando el contrato de eventos esté admitido y CDP cuando una operación de Chromium justifique esa dependencia. Mantén protocolo, biblioteca y entorno del navegador en filas separadas del registro; ninguno sustituye la verificación de los demás.