Planteamiento y alcance
Un equipo desea migrar la interceptación de red del navegador desde un protocolo de depuración privado a WebDriver BiDi. Explique cómo diseñaría la configuración de sesiones, las suscripciones a eventos, el ciclo de vida de la interceptación, el aislamiento de concurrencia y la recuperación ante fallos.
Qué evalúa el entrevistador
- Comprender que BiDi es el protocolo bidireccional e impulsado por eventos de WebDriver y que sigue siendo un Borrador de Trabajo (Working Draft) del W3C.
- Distinguir las responsabilidades de sesión, contexto, id de interceptación, id de solicitud y suscripción a eventos.
- Delimitar la interceptación por patrón de URL, fase y contexto para evitar la contaminación cruzada entre pruebas.
- Diseñar tiempos de espera (timeouts), cancelación, manejo de desconexiones y ofuscación (redaction) en lugar de presentar únicamente un script.
Preguntas para clarificar
- ¿La prueba observa el tráfico o lo modifica/bloquea en las fases de solicitud o respuesta?
- ¿El navegador, el driver y el entorno de ejecución admiten los módulos BiDi requeridos?
- ¿Cada prueba es propietaria de un contexto de navegador y durante cuánto tiempo se retienen las reglas y los registros de eventos?
- En caso de fallo, ¿se debe restaurar la red real o la prueba debe fallar inmediatamente con diagnósticos?
Estructura de respuesta de 30 segundos
Para cada prueba crearía una sesión BiDi y un contexto de navegación aislados, negociaría capacidades y me suscribiría únicamente a los eventos necesarios. Las reglas limitarían la URL, la fase y el contexto; eventos como beforeRequestSent darían lugar a una sola decisión por id de solicitud: continuar, bloquear o proporcionar una respuesta simulada (mock). Cada regla tiene un tiempo de espera y un hook de limpieza. Una desconexión detiene la mutación y marca la prueba como fallo de infraestructura, mientras que los registros conservan solo metadatos ofuscados. El tráfico de producción nunca utiliza este interceptor.
Análisis detallado paso a paso
1. Confirmar los límites del protocolo y de la implementación
WebDriver BiDi utiliza WebSocket para la comunicación bidireccional impulsada por eventos; la versión del W3C del 1 de junio de 2026 sigue siendo un Borrador de Trabajo. El cliente debe leer las capacidades del driver y del navegador en lugar de asumir que los campos del borrador son estables en todas partes. Los comandos HTTP clásicos de WebDriver pueden coexistir con los eventos BiDi, pero un solo canal debe ser la autoridad para cada parte del estado.
2. Crear sesiones y contextos aislados
Al inicio de la prueba, cree una sesión y un contexto de navegación aislado, y registre el mapeo de sesión, contexto e id de ejecución de la prueba. Asigne a cada regla de interceptación un id de interceptación único y vincúlela solo a los patrones de URL, fases y contexto necesarios. En el desmantelamiento (teardown), cancele las suscripciones, elimine las interceptaciones y cierre el contexto en orden inverso para que las reglas no se filtren a la siguiente prueba.
3. Diseñar decisiones de eventos e interceptación
Suscríbase a los eventos de red con session.subscribe, luego use el id de solicitud en cada evento para localizar el estado de la prueba. Una coincidencia recibe exactamente una acción explícita: continuar, bloquear o proporcionar una respuesta en una fase admitida. La capa de decisión necesita una clave de idempotencia y un tiempo de espera. Los id de solicitud desconocidos, los eventos duplicados o las fases no admitidas generan errores observables en lugar de una continuación silenciosa.
4. Manejar concurrencia, desconexiones y seguridad
Las pruebas concurrentes no deben compartir una tabla de interceptación mutable; cada contexto posee sus propias reglas y búfer de eventos. Ante una desconexión de WebSocket, detenga la modificación del tráfico, marque la prueba como fallo de infraestructura, ofusque y retenga la URL, el estado y la cronología, y luego limpie. Ofusque encabezados, cookies, cuerpos y tokens de forma predeterminada. Ejecute solo en navegadores de prueba con credenciales de prueba de corta duración, nunca contra dominios de producción.
Ejemplo de respuesta de alta calidad
Trataría a BiDi como un límite de protocolo, no como copiar una API de enrutamiento de una biblioteca de automatización. Cada prueba obtiene una sesión y un contexto de navegación aislados, lee las capacidades y se suscribe a los eventos de red requeridos. Las interceptaciones tienen identificadores únicos y están limitadas por patrón de URL, fase y contexto; los eventos utilizan identificadores de solicitud para tomar una decisión única: continuar, bloquear o simular. El desmantelamiento cancela suscripciones, elimina reglas y cierra el contexto en orden inverso. Cada acción tiene un tiempo de espera, idempotencia y registro de diagnóstico. Una desconexión de WebSocket hace fallar la prueba como infraestructura y limpia en lugar de mutar el tráfico en un estado desconocido. Los registros se ofuscan, los navegadores de prueba se aíslan de producción y las diferencias de compatibilidad se hacen explícitas en una matriz de capacidades.
Errores comunes
- Tratar los campos de Borrador de Trabajo como API estables en todos los navegadores y drivers.
- Interceptar globalmente por URL sin delimitación de contexto, fase o ejecución de prueba.
- No suscribirse primero, o mezclar identificadores de evento, de interceptación y de contexto.
- Continuar enviando mutaciones después de una desconexión, haciendo que los resultados sean difíciles de interpretar.
- Dejar reglas de interceptación activas después del desmantelamiento y contaminar pruebas posteriores.
- Escribir cookies, encabezados Authorization o cuerpos de respuesta en los registros sin ofuscar.
- Habilitar un interceptor de prueba en navegadores de producción o tráfico de usuarios reales.
Preguntas de seguimiento y respuestas
¿Cómo puede coexistir BiDi con el WebDriver clásico?
El WebDriver clásico es adecuado para el control imperativo, mientras que BiDi es adecuado para eventos continuos y observación de red. Pueden compartir una sesión de navegador, pero la propiedad del estado y el orden de cierre deben ser explícitos para que ambos canales no muten un mismo contexto al mismo tiempo.
¿Por qué las reglas de interceptación necesitan una fase?
Los datos disponibles difieren antes de que se envíe una solicitud, cuando comienza una respuesta y cuando se completa. Una fase selecciona lo que se puede cambiar y permite que las fases no admitidas fallen temprano en lugar de adivinarse en tiempo de ejecución.
¿Cómo demuestra que no hay contaminación cruzada entre pruebas?
Asigne a cada prueba su propio contexto e identificadores de interceptación, consulte y limpie las reglas de ese contexto en el desmantelamiento y ejecute una verificación de aislamiento. Registre los eventos de suscripción, cancelación y cierre para que un fallo conserve una cronología completa.