Noticias Steam Machine
Related Articles
Cualquiera que pruebe aplicaciones web debe conocer un nuevo protocolo de automatización del navegador llamado WebDriver BiDi. Este nuevo protocolo es una evolución del estándar WebDriver original e incorpora algunos de los beneficios de otras herramientas de automatización, en particular la adición de comunicación bidireccional. «Es un protocolo completamente nuevo y toma todas las mejores ideas que han estado en el mercado durante un tiempo y trata de estandarizarlo a través del W3C», dijo David Burns, jefe de código abierto en BrowserStack (una empresa de pruebas de navegadores que está en WebDriver BiDi Working Group) y presidente del Grupo de Trabajo de Herramientas y Pruebas de Navegadores del W3C, que es el grupo responsable de las especificaciones de WebDriver y WebDriver BiDi. El protocolo WebDriver original, o WebDriver Classic, es una «interfaz de control remoto que permite la introspección y el control de los agentes de usuario», según lo define el W3C. Básicamente, proporciona una forma de controlar de forma remota el comportamiento de los navegadores web para que las aplicaciones puedan probarse en ellos. Sin embargo, este protocolo ofrece solo comunicación unidireccional, lo que significa que el cliente envía una solicitud al servidor y el servidor solo puede responder a esa solicitud, explicó Puja Jagani, líder del equipo de BrowserStack y desarrollador del código clave para el proyecto WebDriver BiDi. . “El servidor no puede iniciar la comunicación con el cliente, solo puede responder. Entonces, si sucede algo interesante en los navegadores, no puede comunicarse con el cliente a menos que el cliente lo solicite”, explicó Jagani. BiDi en WebDriver BiDi significa comunicación bidireccional, lo que significa que en realidad permite que los eventos en el navegador se transmitan. al software de control Según Jagani, dado que los navegadores están controlados por eventos, es útil que el navegador pueda compartir eventos con el cliente cuando sucede algo interesante, los usuarios pueden suscribirse a eventos creados cuando se envía una solicitud de red hacia o desde. el navegador, lo que les permite monitorear (o modificar) todas las solicitudes salientes y las respuestas entrantes. Un ejemplo en acción involucra una aplicación que apunta a una producción de base de datos en la nube. Al probar una aplicación de este tipo, WebDriver BiDi se puede utilizar para modificar las solicitudes salientes. apuntar a una base de datos de prueba para que la base de datos de producción no se inunde con datos de prueba. “Esto sólo es posible con comunicación bidireccional. No es posible sin el protocolo BiDi del W3C”, dijo Jagani. CDP vs WebDriver Chrome DevTools Protocol (CDP) y WebDriver Classic históricamente se han comparado a menudo porque ambos son herramientas de bajo nivel: herramientas que ejecutan comandos remotos fuera del navegador, como abrir varias pestañas o simular el modo de dispositivo, Jecelyn Yeen, Chrome El ingeniero senior de relaciones con desarrolladores y Maksim Sadym, ingeniero de software de Google, explicaron esto en una publicación de blog. Las herramientas de alto nivel, por el contrario, son aquellas que ejecutan comandos dentro del navegador. Ejemplos de estos incluyen Puppeteer, Cypress y TestCafe. CDP permite la comunicación bidireccional, pero está limitado para fines de prueba porque solo funciona con navegadores basados en Chromium, como Google Chrome, y no funciona con Firefox o Safari. Según Yeen y Sadym, «WebDriver BiDi pretende combinar los mejores aspectos de WebDriver ‘Classic’ y CDP». Sin embargo, Burns de BrowserStack enfatizó que este nuevo protocolo no pretende reemplazar a CDP, sino que es un protocolo de prueba y automatización completamente nuevo. «CDP siempre estará presente en los navegadores Chromium», dijo. Ya tiene soporte para navegador. El creador de CDP, Google, está muy involucrado en el desarrollo y soporte de WebDriver BiDi, al igual que Mozilla. «Estamos contentos de que Mozilla y Google hayan venido y nos hayan ayudado a llegar al punto en que esté estandarizado y ahora todos puedan beneficiarse de ello», dijo Burns. Añadió que Apple aún no ha llegado a ese punto y que no está claro en este momento cuándo estará disponible el soporte para WebDriver BiDi en los navegadores basados en WebKit. “A veces los estándares pueden cambiar a un ritmo glacial, y en parte eso se debe a una buena razón. Implica crear puntos de colaboración y lograr consenso, y a veces el consenso puede ser realmente difícil, especialmente cuando Google, Mozilla y Apple tienen sus propias ideas sobre qué hace que algo sea mejor, y luego lograrlo puede ser muy, muy lento de implementar. explicó Burns. Las herramientas de automatización de pruebas y las empresas de pruebas también han comenzado a respaldarlo. Además de los navegadores que deben admitirlo, otra pieza del rompecabezas tiene que ver con las herramientas de automatización de pruebas y los proveedores de pruebas. Afortunadamente, las herramientas de automatización Selenium y WebDriverIO, así como las empresas de pruebas BrowserStack, SauceLabs y LambdaTest, forman parte del grupo de trabajo WebDriver BiDi. WebdriverIO y Selenium ya son compatibles con el nuevo protocolo y BrowserStack también lo admite. El propio Selenium también está actualizando toda su implementación de WebDriver a WebDriver BiDi. Burns explicó que actualizar la versión clásica de WebDriver a BiDi es la última parte importante del proceso y se espera que se complete durante el próximo año. “Es un proyecto impulsado por voluntarios, por lo que esto sucede cuando el ancho de banda y el tiempo de todos coinciden, por lo que se realiza en ráfagas o ráfagas de trabajo, ¿verdad? Pero creo que ese es el caso del desarrollo de código abierto en general», dijo Jagani, quien también es miembro del Comité de Liderazgo Técnico de Selenium. Señaló que con Selenium 5 (la versión actual es 4.24), el objetivo es completar al menos las API de alto nivel, que cubren una serie de casos de uso, como brindar al usuario la capacidad de escuchar los registros de la consola y la capacidad de realizar una autenticación básica para su sitio web, por nombrar algunos. Una vez que Selenium 5 esté disponible, el siguiente. El objetivo será comenzar a realizar la transición de comandos uno por uno de WebDriver Classic a WebDriver BiDi. «Con suerte, para Selenium 6, solo seremos BiDi», dijo y explicó que es un proceso que incluye muchas variables externas. aún se está implementando, y una vez que BiDi esté en la versión estable del navegador, será cuando Selenium entrará en acción y podrá comenzar a implementarlo. Después de eso, todavía hay un período en el que los usuarios deberán usarlo y proporcionar comentarios para que Selenium pueda. garantizar que su implementación sea resiliente. Jagani dijo que la experiencia del usuario debería seguir siendo la misma una vez que Selenium cambie a BiDi y que no habrá cambios importantes. «Esto es lo que Selenium intenta hacer, incluso desde Selenium 3 a 4, intentamos garantizar una integración perfecta con cambios mínimos», dijo. “El selenio es muy importante cuando se trata de compatibilidad con versiones anteriores, o al menos garantiza que estemos desaprobando cosas según sea necesario para que sepas que lo eliminaremos y brindaremos suficientes advertencias. La experiencia para los usuarios que usan WebDriver Classic seguirá siendo la misma, porque en el futuro. Al final habrá la misma API, usando solo BiDi». Para aprovechar las nuevas funciones avanzadas que ofrece BiDi, estarán disponibles API más nuevas, similares a aquellas con las que los usuarios ya están familiarizados.
