Eventos WebDriver BiDi para una automatización estable
Comprende las sesiones, eventos y límites de transporte de WebDriver BiDi para una automatización de navegador mantenible.
Quieres la documentación estructurada de Primeros pasos?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
WebDriver BiDi ofrece un canal estándar en ambas direcciones. El cliente puede enviar un comando mientras el navegador publica un evento, de modo que una prueba observe navegación, registros, red y contextos sin convertir cada transición en una espera arbitraria. Un evento es evidencia del navegador, no prueba de que la aplicación o un servicio aceptara una operación.
La práctica útil es tratar una ejecución BiDi como un sistema pequeño: sesión negociada, transporte con propietario, suscripciones explícitas y aserciones visibles para la persona usuaria. Estos límites hacen más claro el diagnóstico. La guía inicial de Playwright aporta contexto sobre el ciclo del navegador y la validación de interacción cubre evidencia que queda fuera de un evento.
La separación importa en el mantenimiento diario. Una prueba puede observar una navegación, un mensaje de consola o una respuesta mientras la aplicación aún decide qué mostrar. Un comando correcto del controlador tampoco demuestra que el servidor aceptó los datos. Nombrar por separado la observación y el resultado permite distinguir un cambio de página, controlador, transporte o servicio.
Qué cambia con WebDriver BiDi
WebDriver clásico está orientado a solicitudes: el cliente envía un comando y recibe una respuesta. BiDi añade una conexión duradera para que el navegador envíe eventos sin esperar otra solicitud. La especificación W3C WebDriver BiDi define comandos, eventos y contextos de navegación.
Un evento no reemplaza una aserción. log.entryAdded indica que el navegador observó una entrada de consola, pero no que el servidor guardó algo ni que el flujo terminó bien. Un evento de red describe una categoría de solicitud o respuesta, mientras la página puede mostrar un error. Combina el evento con la aserción mínima que representa el resultado esperado.
BiDi separa observación e implementación. El cliente se suscribe a tipos de evento y puede limitar el contexto de navegación. Eso es más claro que recoger todos los mensajes y buscar después. La suscripción no es por sí sola un límite de privacidad: una prueba autorizada necesita reglas para URL, cabeceras, argumentos y contenido. Conserva solo metadatos necesarios.
El protocolo evoluciona y el soporte varía según navegador y controlador. Una sesión puede conectarse y aun así rechazar un comando, omitir un campo opcional o cerrarse cuando una función no existe. Registra capacidades negociadas y versiones. Clasifica el soporte ausente aparte del fallo de la aplicación para que no se convierta en un tiempo de espera engañoso.
Negocia una sesión que puedas administrar
Crear la sesión es el momento de declarar expectativas y recibir identificadores para usar después. Mantén juntas la configuración, el perfil, la política de registros y las capacidades solicitadas. Una capacidad solicitada no garantiza implementación. Lee la respuesta, conserva los valores aceptados y decide a partir de ellos.
Los contextos son otro límite de propiedad. Una pestaña, un marco y una ventana nueva pueden tener identificadores distintos. Guarda esos identificadores cuando el dispositivo los crea o descubre. Con varios contextos, dirige cada evento al caso que posee su contexto e ignora notificaciones ajenas para evitar carreras entre pestañas.
La fijación debe definir cuándo la sesión está lista y cuándo deja de servir. Puede exigir un saludo correcto, un contexto conocido y una confirmación de suscripción. Al cerrar, detén acciones nuevas, retira escuchas, solicita el cierre admitido y cierra el transporte. Usa una ruta finally porque un callback puede fallar aparte del comando.
Haz determinista la configuración. Cada trabajador necesita un perfil y una ruta de artefactos propios; registra navegador, controlador y versión del protocolo. No reutilices una sesión desconocida. La documentación bidireccional de Selenium describe el modelo del cliente, mientras el equipo conserva la responsabilidad de datos, servidor y retención.
Suscríbete a eventos sin perder el contexto
Las suscripciones deben ser tan estrechas como la pregunta. Para un error de página, filtra el evento de registro por el contexto probado. Para una navegación, conserva identificador, categoría de URL y hora permitida por la política. Filtrar pronto reduce trabajo y evita capturar actividad de otras páginas.
El manejador debe tener pocos efectos laterales. Puede añadir un registro acotado, resolver una espera con nombre o actualizar una máquina de estados. No debe hacer clic, enviar formularios, cambiar almacenamiento ni abrir otra sesión. Así un evento no provoca acciones duplicadas ni carreras reentrantes.
El orden de eventos solo vale dentro de las garantías del protocolo y su implementación. Una solicitud puede llegar antes de que la página muestre el resultado, y un registro puede llegar después del comando. Usa el evento como marca y espera el estado visible. Si hay varios finales válidos, nómbralos y clasifica el primero.
Los eventos tardíos son normales durante el cierre. Marca la sesión como cerrándose antes de retirar escuchas, y descarta mensajes posteriores al estado terminal. Limita la cola e informa de desbordamientos. Si una suscripción se rechaza, registra el nombre y continúa solo con un respaldo aprobado; de lo contrario, indica falta de capacidad.
Trata el transporte como un ciclo de vida
El transporte BiDi es una conexión duradera que lleva comandos, respuestas y eventos no solicitados. El cliente correlaciona cada respuesta con su identificador y distribuye eventos a sus suscriptores. Deja esa correlación en la biblioteca; el caso de prueba debe recibir un resultado con nombre, no analizar tramas crudas.
Una desconexión puede ocurrir con un comando pendiente o durante eventos. Distingue cierre limpio, error de transporte, caída del navegador y tiempo de espera de la aplicación. Reconectar no siempre es seguro: repetir un envío puede duplicar una operación. Reintenta solo preparaciones idempotentes bajo una política explícita y crea una sesión nueva cuando no puedas probar el estado anterior.
Aplica una política de presión de cola. Muchos registros o eventos de red pueden ocultar el mensaje relevante. Filtra al suscribirte, limita registros retenidos e indica si hubo descartes. Redacta valores antes de escribir artefactos, especialmente URL con consultas, cabeceras y argumentos. El protocolo ofrece datos, pero no decide cuáles debe conservar el equipo.
Los tiempos de transporte deben indicar qué capa dejó de avanzar. Un tiempo de respuesta de comando, una espera de evento y una espera de página significan cosas distintas. Incluye nombre, contexto permitido, estado de conexión y última categoría observada. No conviertas una desconexión en un tiempo de página genérico.
Construye aserciones estables orientadas a eventos
Empieza con un resultado declarado y un modelo pequeño. En un flujo de compra autorizado puede haber carrito sintético, envío, estado visible y fallo acotado. BiDi observa navegación o respuesta, pero la aserción estable es el estado que una persona puede leer. Nombrar primero el resultado evita una colección de señales convenientes.
Usa una espera por transición y dale un nombre semántico. Una espera de contextCreated termina cuando aparece el contexto esperado; otra espera el encabezado de confirmación. Los predicados deben leer, no mutar, y sus límites deben ser configuración del entorno. Conserva el nombre de la condición cuando cambie el límite.
El artefacto de fallo debe conservar la primera condición ausente. Registra capacidades aceptadas, acción, categoría de evento, propiedad de contexto y versiones, con observaciones redactadas. Una captura puede servir en un fixture sintético aprobado, pero no hace falta volcar una página autenticada. La guía de ciclo BrowserContext de Puppeteer trata una propiedad y limpieza similares.
Ensaya rutas negativas. Retira una señal de preparación en un fixture sintético y confirma un tiempo acotado que nombre esa señal. Simula una suscripción rechazada o un transporte cerrado y verifica que se clasifique como problema de entorno o capacidad, no como éxito. El ensayo evita datos privados y cuentas reales.
Usa BotBrowser con límites claros
BotBrowser puede proporcionar contextos aislados y perfiles repetibles para ejecuciones autorizadas que observan WebDriver BiDi. Esto ayuda a comparar las mismas entradas de sesión y mantener clara la propiedad del perfil. BotBrowser no implementa el protocolo WebDriver BiDi, no añade comandos ni eventos no admitidos y no garantiza compatibilidad entre controlador, navegador, transporte y aplicación. La implementación del protocolo y el resultado del servidor siguen perteneciendo a la pila elegida.
El aislamiento mantiene separados el almacenamiento y el estado sintético, pero no autoriza por sí solo una prueba. Define páginas, datos y campos que la ejecución puede leer. Mantén perfiles y artefactos bajo propiedad del trabajador y cierra la sesión por su ciclo admitido. Un inicio repetible mejora la comparación, pero no garantiza un evento ni la aceptación de un servicio.
Al usar BotBrowser con un controlador BiDi, registra la combinación real y las capacidades aceptadas. Si falta un comando, atribuye el límite al componente que lo rechazó. No confundas aislamiento de perfil con conformidad del protocolo ni un perfil repetible con una transacción completada. La validación del producto y la conformidad deben seguir separadas.
Lista de revisión para equipos BiDi
Antes de ejecutar, confirma propietario de sesión, perfil, transporte, capacidades y suscripciones. Decide qué contexto posee cada aserción y qué datos llegan a los registros. Declara el estado visible de finalización y las señales que lo apoyan. Así el fixture es revisable y no un servicio opaco.
Durante la ejecución, correlaciona respuestas y enruta eventos mediante un manejador consciente del contexto. Mantén manejadores acotados y sin efectos laterales. Separa comandos no admitidos, desconexiones, desbordamientos y tiempos de página. Si un reintento es seguro, explica por qué y crea sesión nueva cuando no puedas probar la anterior.
Después, cierra escuchas y sesión aunque falle una aserción. Conserva solo evidencia sintética aprobada, incluida la primera condición ausente y las capacidades aceptadas. Compara por resultado y combinación de compatibilidad, no por tiempos accidentales. Ante un cambio de navegador o controlador, repite las comprobaciones.
El contrato duradero es sencillo: BiDi lleva comandos y observaciones, el fixture administra sesión y transporte, y la aplicación define la finalización. Separar responsabilidades hace preciso un fallo sin convertir un evento en garantía de negocio.
Los equipos pueden dejar este contrato junto a cada recorrido: comando que inicia, evento que observa, contexto propietario, aserción reconocible y respaldo cuando falta un evento. No hacen falta tramas crudas; basta contexto para distinguir regresión, capacidad no admitida o conexión perdida.
El registro también debe indicar limpieza. Un contexto hijo necesita dueño, una suscripción necesita momento de retirada y un artefacto necesita frontera de datos sintéticos. Esto evita que un evento tardío llegue a otra prueba y que un perfil fallido altere la siguiente. BiDi aporta el mecanismo; los dueños del fixture y la aplicación fijan la política.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.