1. Introducción a la Automatización del Navegador
Soy Michael Hablich, un gerente de producto en el equipo de Chrome, trabajando en reducir la fricción de probar y depurar aplicaciones web. Hoy hablaré sobre las técnicas de automatización del navegador y por qué estamos agregando una cuarta, el controlador web. La garantía de calidad y las actividades de prueba representan una gran parte del costo de desarrollo de software, y la automatización de pruebas es una forma muy buena de reducir los costos continuos de prueba. La automatización del navegador automatiza las interacciones del usuario y finge ser un usuario, con casos de uso típicos que incluyen la automatización de pruebas, la extracción de datos web y la representación de partes de páginas como anuncios. Hagamos un breve recorrido por la historia de la automatización del navegador, desde las API nativas en los años 90 hasta las complejidades de los applets de Java y Flash en los años 2000.
fricción de probar y depurar aplicaciones web. Hoy tengo el honor de hablar sobre las técnicas de automatización del navegador y por qué estamos agregando una cuarta, el controlador web. He pasado alrededor de 20 años trabajando en tecnología. Gran parte de esto ha sido construyendo soluciones de automatización de pruebas para empresas. Se podría decir que me he divertido mucho automatizando navegadores, aplicaciones .NET y tecnologías más especializadas como Power Builder. Entonces, ¿por qué estoy aquí? Bueno, el equipo de Chrome revisa periódicamente la satisfacción de los desarrolladores web y, sorpresa, la prueba, en particular, en diferentes navegadores, es uno de los principales puntos problemáticos para los desarrolladores web. La garantía de calidad y las actividades de prueba representan una gran parte del costo de desarrollo de software, y no se pueden eliminar fácilmente. La garantía de calidad es necesaria porque o bien sus aplicaciones de prueba o sus usuarios están llenos, y esto último tiene cierto riesgo asociado. Y la automatización de pruebas es una forma muy buena de reducir los costos continuos de prueba. Entonces, primero definamos un poco en qué consiste la automatización del navegador y veamos brevemente cómo funciona. La automatización del navegador simplificada automatiza las interacciones del usuario y finge ser un usuario. A menudo, estas interacciones se almacenan como código fuente, como se ve en el lado izquierdo. Estas interacciones se reproducen, como se puede ver en el lado derecho. Los casos de uso típicos de las tecnologías de automatización del navegador son la automatización de pruebas, la extracción de datos web o la representación de partes de páginas como anuncios. Hoy me enfocaré en la primera automatización de pruebas. Las diapositivas anteriores mostraron el estado actual de la automatización del navegador, pruebas definidas en JSON y
JavaScript. Automatización rápida y estable, y así sucesivamente. Antes de llegar a este lugar tan acogedor, ocurrió mucha historia. Hagamos un breve recorrido. La web nació en los años 90. Las personas comenzaron a usar navegadores en un conjunto limitado de pantallas grandes. Las pruebas en estas décadas se realizaron principalmente con contenido. Navegadores como Netscape Navigator o Internet Explorer fueron lanzados. La automatización del navegador en ese momento se realizaba a través de las API nativas. Por ejemplo, todavía recuerdo usar Visual Basic 6 para automatizar Internet Explorer. En 1996, los applets de Java y Flash se hicieron populares. Esto complicó aún más la automatización de páginas web porque las API de automatización del navegador proporcionadas por los proveedores de navegadores no funcionaban para aplicaciones Java y contenedores Flash. Las pruebas manuales o la inyección de scripts eran la forma de proceder para estas tecnologías. En los años 2000, más navegadores se unieron
2. Técnicas de Automatización del Navegador
Los desarrolladores comenzaron a construir experiencias web ricas e interactivas. Selenium y WebDriver fueron creados para abordar los desafíos de automatización de pruebas, siendo WebDriver un estándar de W3C. Se introdujeron múltiples bibliotecas de pruebas de JavaScript que utilizaban diferentes técnicas para automatizar navegadores. Cubriremos el Protocolo WebDriver, el Protocolo Chrome DevTools y las API web junto con las extensiones del navegador. Hay dos categorías principales: alto nivel, ejecutando JavaScript inyectado, y bajo nivel, ejecutando comandos remotos. Nos centraremos en el enfoque de utilizar las API web y las extensiones del navegador para construir una capa de automatización.
escenas, incluyendo Chrome. Los desarrolladores comenzaron a construir experiencias muy ricas e interactivas en la web. YouTube y Google Maps son algunos ejemplos tempranos muy buenos de esto. Con la aparición de los teléfonos inteligentes, aumentó la necesidad de automatización de pruebas debido a la compatibilidad entre navegadores y dispositivos. Surgieron Selenium y el proyecto WebDriver para resolver los desafíos de automatización de pruebas. En ese momento, era común escribir pruebas de Selenium en Java. En 2009,
Node.js llevó el desarrollo de
JavaScript al
backend. Además, permitió ejecutar pruebas escritas en
JavaScript. Aparecieron más
frameworks de
JavaScript. Al mismo tiempo, Selenium y WebDriver se fusionaron en un solo proyecto llamado Selenium-WebDriver. Con la creciente popularidad, el proyecto se convirtió en un estándar de W3C en 2018, y lo llamamos WebDriver Classic. Con más desarrolladores construyendo aplicaciones más ricas en
JavaScript, estos desarrolladores también querían realizar automatización de pruebas en
JavaScript. Se introdujeron múltiples bibliotecas de pruebas basadas en la web en respuesta a estas necesidades, y no todas utilizan WebDriver como tecnología de automatización subyacente. Utilizan diferentes técnicas para automatizar el navegador, de las cuales hablaremos hoy. Cubriremos el Protocolo WebDriver, utilizado por soluciones como Selenium, Nightwatch.js o WebDriverIO, el Protocolo Chrome
DevTools, CDP en resumen, que impulsa Puppeteer, la propia biblioteca de automatización de Chrome, y PlayWrite, y las API web junto con las extensiones del navegador, utilizadas por Taskcafe o
Cypress, por ejemplo. Comencemos y retrocedamos un poco y hablemos de cómo las herramientas automatizan los navegadores. Mencioné tres formas principales de automatizar un navegador. Bueno, también se dividen en dos categorías principales. Intensifiquemos un poco la complejidad, porque tenemos el alto nivel, que ejecuta
JavaScript inyectado en el navegador, y el bajo nivel, que ejecuta comandos remotos. Por ejemplo,
Cypress utiliza extensiones del navegador y
Node.js para ejecutar una prueba directamente en el navegador. Para tener un mayor control del navegador, como abrir múltiples pestañas y probar iframes de terceros, debemos profundizar y ejecutar comandos remotos. Con otras técnicas, y llamémoslo simplemente protocolos. Los dos protocolos comunes son WebDriver, Chrome, y el protocolo
DevTools de Chrome, Cpp en resumen. Exploraremos todo esto juntos en breve. No se preocupen. Voy a comenzar con el enfoque de utilizar las API web y las extensiones del navegador para construir su propia capa de automatización. Esencialmente, las soluciones aprovechan y lanzan las API web, la inyección de JS, extensiones del navegador, proxies, etc., para construir su propia capa de automatización. Detallar esto aquí sería demasiado extenso para la charla. Así que me detendré aquí y pasaré a WebDriver, la técnica de automatización basada en un estándar. Es uno de los niveles bajos.
3. Automatización de Casos de Prueba con Controladores de Navegador
Supongamos que eres un desarrollador web o un tester que desea automatizar un caso de prueba. Tus herramientas de automatización traducen tus scripts a HTTP y se comunican con los controladores de navegador a través de comandos de controlador web. Los controladores de navegador luego se comunican con el navegador a través de protocolos internos específicos del navegador. Veamos un ejemplo de un script en WebDriver I.O. Cada acción se traduce en solicitudes HTTP. Los controladores de navegador manejan las solicitudes y envían la respuesta a través de la misma conexión HTTP. Sin embargo, esperar a que los elementos aparezcan en la pantalla puede ser complicado, ya que los controladores de navegador no pueden notificar a las bibliotecas de automatización. Las bibliotecas deben enviar constantemente solicitudes para verificar el estado.
protocolos. Así que echemos un vistazo breve a cómo funcionan en principio. Supongamos que eres un desarrollador web o un tester que desea automatizar un caso de prueba, el caso de uso más común para la automatización del navegador. Eliges una herramienta de automatización de pruebas y escribes pruebas en ella. Luego, ejecutas estas pruebas como parte de tu
CI. Detrás de escena, tus herramientas de automatización traducirán tu script y lo ejecutarán en el navegador a través de algún tipo de protocolo, como el controlador web o CDP, por ejemplo. Aquí puedes ver que hay una entidad agregada entre las herramientas de automatización y los navegadores, los controladores de navegador. Por lo general, estos deben instalarse por separado para automatizar un navegador a través del controlador web. Tus herramientas de automatización traducen tus scripts a HTTP y se comunican con los controladores de navegador a través de comandos de controlador web. Los controladores de navegador luego se comunican con el navegador a través de protocolos internos específicos del navegador. Dado que WebDriver Classic es un estándar web, es compatible con todos los principales proveedores de navegadores. Para cada nueva versión, estos navegadores actualizarán y publicarán una nueva versión del controlador. Veamos un poco de código real. Chaseline, un excelente defensor del desarrollador de Chrome
Tooling, creó demos increíbles. Ahora las voy a mostrar en las diapositivas siguientes. Así que gracias, Chaseline. Veamos un ejemplo aquí. Digamos que tienes un script para navegar a una página y hacer clic en un café para agregarlo a tu carrito de compras. Así es como se ve el script en WebDriver I.O. Cada acción se traducirá en solicitudes HTTP, por ejemplo. ¿Qué sucede cuando estableces el tamaño de la ventana es que tus herramientas de automatización envían una solicitud HTTP para cambiar la ventana. Aquí hay una demostración de cómo establecer el tamaño de la vista en el navegador Safari. En nuestro ejemplo, estos son los tres comandos HTTP que ocurren detrás de escena. La mayoría de las veces, el controlador del navegador maneja las solicitudes y envía la respuesta a través de la misma conexión HTTP. Sin embargo, el segundo paso es un poco complicado. Muchas veces necesitas esperar hasta que el elemento se muestre en la pantalla. En nuestro caso, el café se carga desde una solicitud de red. Necesitamos esperar a que eso suceda antes de poder encontrarlo y hacer clic en él. Debido a la naturaleza de HTTP, los controladores de navegador no pueden notificar a las bibliotecas de automatización cuando el café está listo. Las bibliotecas deben enviar constantemente una solicitud. ¿Está el espresso allí? ¿Ya está? ¿Es el elemento
4. Protocolos de Automatización y Chrome DevTools
El controlador de navegador es inferior en comparación con otros protocolos porque cada comando clásico requiere un saludo HTTP. WebDriver Classic tiene el mejor soporte multi-navegador pero tiene limitaciones en el soporte de algunos controles de bajo nivel. El protocolo Chrome DevTools permite la depuración y automatización de sitios web. Puppeteer utiliza CDP internamente para comunicarse directamente con navegadores basados en Chromium. CDP admite más controles y características de bajo nivel como la interceptación de solicitudes de red y la simulación del modo de dispositivo.
y así sucesivamente. Y el controlador de navegador va a verificar el estado. A partir del ejemplo anterior, sabemos que el controlador de navegador es inferior en comparación con otros protocolos porque cada comando clásico requiere un saludo HTTP. Obviamente, esto es solo una simplificación y existen técnicas para enmascarar y mitigar esto hasta cierto punto. En resumen, WebDriver Classic tiene el mejor soporte multi-navegador. Sin embargo, es inferior y tiene limitaciones en el soporte de algunos controles de bajo nivel , lo cual veremos más adelante. A continuación, echemos un vistazo al protocolo
DevTools de Chrome. Por el nombre, puedes suponer que este protocolo está diseñado para habilitar a
DevTools de Chrome para depurar páginas web. Resulta que muchas de las características necesarias para depurar un sitio web también se pueden utilizar para automatizar un sitio web. Por ejemplo, no importa realmente si queremos obtener el texto interno de un elemento
HTML para mostrarlo en
DevTools de Chrome o para verificar el texto interno en una de tus pruebas. Dado que el protocolo es rápido y potente, Puppeteer utiliza CDP internamente con fines de automatización. A diferencia de WebDriver, CDP se comunica directamente con navegadores basados en Chromium. No se necesita un controlador de navegador, ya que básicamente ya están incluidos. Las herramientas de automatización emiten comandos a través de CDP, y estos comandos se envían al navegador a través de WebSockets. Aquí tienes un recordatorio rápido de nuestra demostración. Vamos a navegar a una página y luego hacer clic en la entrada de Espresso para agregarlo a nuestro carrito. Así es como se ve Puppy The Script para nuestro café. Se parece mucho al ejemplo anterior con WebDriver I.O. Cada acción se traducirá en comandos CDP. Por ejemplo, lo que sucede cuando navegas a una página es lo siguiente. Aproximadamente estos comandos aquí. Primero, navegamos a una página, luego encontramos un café y tercero, lo agregamos a nuestro carrito. Aquí, por ejemplo, puedes ver cómo emitir estos comandos CDP directamente en
DevTools con un monitor de protocolo. En caso de que quieras probarlo tú mismo, deberás habilitar el monitor de protocolo en la configuración de
DevTools, pero en fin. Volviendo a Puppeteer y cómo utiliza CDP para automatizar el navegador. CDP utiliza WebSocket, por lo tanto, las comunicaciones son bidireccionales por defecto. Una vez que el navegador completa la solicitud, envía las actualizaciones de vuelta a las herramientas automáticamente. No es necesario hacer una espera para el café, por lo que no hay un retraso artificial. Además, dado que CDP está diseñado para cubrir todas las necesidades de depuración, admite más controles de bajo nivel en comparación con WebDriver. Admite características como la interceptación de solicitudes de red, la simulación del modo de dispositivo y la geolocalización, así como la obtención de mensajes de consola y así sucesivamente. En el pasado, cuando se desarrolló el protocolo WebDriver, no había necesidad de un control de bajo nivel. Sin embargo, los tiempos han cambiado y ahora la
testing requiere más y
5. Proyecto de Bidireccionalidad de WebDriver
Aunque CDP es rápido y con control de bajo nivel, solo funciona en navegadores basados en Chromium y tampoco es un estándar. WebDriver es relativamente lento y no lo suficientemente de bajo nivel. El proyecto de Bidireccionalidad de WebDriver tiene como objetivo combinar las partes buenas de ambos protocolos, ofreciendo mensajería bidireccional, controles de bajo nivel, soporte multi-navegador y estandarización. Complementa a WebDriver y reduce la necesidad de que las bibliotecas de automatización utilicen directamente CDP. Sin embargo, el protocolo WebDriver aún está en desarrollo, con especificaciones e implementaciones que están siendo finalizadas por los proveedores de navegadores y las bibliotecas de automatización de pruebas.
más acciones detalladas. Aunque CDP es rápido y tiene control de bajo nivel, solo funciona en navegadores basados en Chromium y tampoco es un estándar. Entonces, lo que podemos ver es que ambos protocolos de automatización de navegadores tienen sus desventajas. CDP no es un estándar y es específico del navegador. WebDriver es relativamente lento y no lo suficientemente de bajo nivel. Pero ambos protocolos también ofrecen beneficios únicos. CDP es rápido y bidireccional. Proporciona control de bajo nivel sobre el navegador. WebDriver está diseñado para pruebas y es un estándar con soporte multi-navegador. Entonces, ¿qué pasa si tomamos solo las partes buenas de ambos protocolos? Eso es lo que trata el proyecto de Bidireccionalidad de WebDriver. Es un nuevo estándar para la automatización de navegadores, que combina las partes buenas de WebDriver y CDP. Tiene mensajería bidireccional, controles de bajo nivel, soporte multi-navegador y estandarización. Está diseñado para pruebas y no para depuración. Este diagrama se parece mucho a lo que ya has visto para CDP y WebDriver. Bueno, la razón es porque WebDriver Bidirection funciona como una combinación de ambos, por supuesto. Los comandos de WebDriver Bidirection se envían a través de conexiones WebSocket. El receptor puede ser un controlador clásico como el controlador de Chrome o el navegador directamente. Sin embargo, hay algunas cosas importantes a tener en cuenta aquí. WebDriver Bidirection debería complementar a WebDriver. Los comandos bidireccionales y los comandos clásicos pueden ejecutarse uno al lado del otro. No es necesario realizar una migración completa. Hablaré sobre esto en unos minutos con un poco más de detalle. Además, la necesidad de que las bibliotecas de automatización utilicen directamente CDP debería disminuir drásticamente. De hecho, estamos trabajando en hacer que Puppeteer también utilice Bidi en lugar de CDP directamente bajo el capó. Como se mencionó antes, WebDriver Bidi combina los beneficios de CDP y WebDriver. Es importante tener en cuenta que este nuevo estándar es una colaboración de varios proveedores de navegadores, marcos de pruebas y proveedores de infraestructura de pruebas.
Ahora, las malas noticias. Siempre hay malas noticias, ¿verdad? Entonces, el protocolo WebDriver aún está en desarrollo. Los proveedores de navegadores y las bibliotecas de automatización de pruebas aún están trabajando en finalizar las especificaciones y las implementaciones. Si estás interesado en más detalles, consulta el práctico código QR, que abrirá un panel que muestra el soporte del navegador para WebDriver Bidi.
6. WebDriver Bidi y Monitoreo de Consola
WebDriver Bidi todavía está en progreso, pero partes de él ya se están implementando de forma incremental. Las bibliotecas de automatización como Selenium, WebDriver IO y Puppeteer tienen soporte inicial para Bidi. WebDriver Bidi permite monitorear los mensajes de la consola, lo cual puede ser útil para pruebas y detección de errores. Una demostración muestra cómo configurar el navegador, habilitar la URL del socket web y monitorear los mensajes de registro con ByteEye. Esta funcionalidad funciona tanto en Firefox como en Puppeteer. WebDriver ByteEye combina una automatización estable y es una buena opción para la automatización del navegador. Puedes probarlo hoy mismo si tu navegador y biblioteca de automatización de pruebas lo admiten y proporcionar comentarios.
Suficiente de malas noticias, sin embargo. Hablemos de las buenas noticias. Son más importantes de todos modos. Acabo de decirte que WebDriver Bidi todavía está en progreso. Eso es cierto. Estamos implementando partes de WebDriver Bidi de forma incremental, lo que significa que en realidad ya puedes comenzar a usarlo hoy mismo. Las bibliotecas de automatización como Selenium, WebDriver IO o Puppeteer ya tienen soporte inicial para Bidi. ¿Qué significa esto en la práctica para ti como desarrollador web? ¿Cómo puedes beneficiarte de esto hoy? Bueno, si miras el enlace que proporcioné antes, donde se puede hacer un seguimiento del soporte multi-navegador de WebDriver Bidi. Resulta que WebDriver Bidi tiene la capacidad de monitorear los mensajes de la consola. Esa capacidad es parte de la entrada de registro Red Circle allí. ¿Cómo va a ser útil esto? Vamos a mostrarlo nuevamente con una demostración proporcionada nuevamente por Jesslyn. Volvamos a un ejemplo anterior donde estamos ordenando un café. Es común que llamemos a alguna API de análisis adicional cuando un usuario realiza alguna acción como agregar café al carrito. Y queremos asegurarnos de que estas API se llamen durante la prueba. Y queremos monitorear si hay errores en la consola. Entonces, para averiguar si algo está saliendo mal. Esta demostración aquí va a utilizar Web Drive AO como ejemplo. Primero, necesitamos configurar el navegador y habilitar la URL del socket web en la configuración. En este caso, uso Chrome aquí, pero también funciona en Firefox. Después de la configuración, podemos comenzar a monitorear los mensajes de registro con ByteEye. Hay dos partes del código que hacen que esto suceda. Primero, debes suscribirte al evento de registro en la sesión. Y luego puedes escuchar el evento y manejarlo. En este caso, simplemente imprimiríamos los datos, pero se puede hacer mucho más con ellos, por supuesto. Esta es una demostración que se ejecuta en Firefox. Observa la salida. El mensaje de la consola y el error de la página web se capturan correctamente y se procesan. Esto también funciona en Puppeteer, que también está comenzando a utilizar WebDriver ByteEye bajo el capó. Aquí puedes ver lo mismo hecho en Puppeteer. Inicia Puppeteer con el protocolo WebDriver ByteEye. Luego estás listo para monitorear el evento con ByteEye en lugar de CDP. Así que resumiendo. La automatización del navegador es difícil. No hay una única forma de automatizar el navegador. WebDriver ByteEye combina los beneficios de la automatización más estable lo que, en mi opinión completamente imparcial, lo convierte claramente en una buena elección. Puedes probar las primeras partes de WebDriver ByteEye hoy mismo, si tu navegador y la biblioteca de automatización de pruebas lo admiten, por supuesto, y si lo haces, no olvides darnos tu opinión. Y con eso, te deseo un día agradable y felices pruebas.
TestJS Summit 2021
JSNation 2022
React Summit 2023
Comments