En esta sesión, echaremos un vistazo a lo que ha sucedido detrás de escena en la automatización del navegador a lo largo de los años y lo que el futuro nos depara. Examinaremos cómo se desarrollará la prueba web y qué desafíos traerá esto para los marcos convencionales como Selenium o WebdriverIO, así como para los nuevos marcos como Cypress, Puppeteer y Playwright. Por último, experimentaremos con algunas nuevas capacidades de automatización que estos marcos proporcionan para probar algunas de las nuevas características web.
La Evolución de la Automatización del Navegador
Video Summary and Transcription
La automatización del navegador ha evolucionado a lo largo de los años, comenzando con Selenium y WebDriver. Herramientas como Cypress, Taskerfee, Puppeteer y Playwise utilizan enfoques diferentes para la automatización. El nuevo protocolo WebDriver permitirá enviar y recibir miles de comandos y mensajes simultáneamente. Continuarán surgiendo nuevos tipos de pruebas, como las pruebas de rendimiento y accesibilidad. El nuevo protocolo WebDriver combina lo mejor de los tres enfoques y brinda oportunidades para probar y automatizar aplicaciones web.
1. Introducción a la Automatización del Navegador
Hola a todos. Gracias por unirse a la sesión. Soy Christian, trabajo en Sauce Labs. Hablemos sobre la automatización del navegador y sus conceptos erróneos. La automatización del navegador ha evolucionado a lo largo de los años, comenzando con Selenium y WebDriver. Jason y Simon fusionaron los proyectos para superar limitaciones. Se formó un grupo de trabajo en el W3C para estandarizar el proceso.
2. Evolución de la Automatización del Navegador
El objetivo era garantizar la consistencia en todos los navegadores y redactar un estándar para la automatización del navegador. Esto llevó al desarrollo de WebDriver IO y Appium. Sin embargo, el panorama web cambió con aplicaciones dinámicas basadas en JavaScript, la separación entre el front-end y el back-end, y la aparición de nuevas API web. Herramientas como Cypress llenaron los vacíos, mientras que el estándar recomendado quedó corto. Se desarrolló un nuevo protocolo para abordar los requisitos de las aplicaciones web modernas. Las herramientas convencionales como Selenium utilizan el protocolo WebDriver, mientras que las herramientas no estándar ofrecen sus propias ventajas y limitaciones. Proyectos como Cypress, Taskerfee, Puppeteer y Playwise utilizan enfoques diferentes para la automatización.
El objetivo aquí era asegurarse de que un clic en, por ejemplo, Chrome fuera igual que un clic en Firefox. Por lo tanto, las personas comenzaron un esfuerzo para redactar un estándar con los requisitos en mente que las personas tenían en ese momento en cuanto a la automatización del navegador. Esto generó mucha confianza y tracción en el ecosistema, donde comenzaron a surgir y crearse muchos nuevos proyectos. Vemos el lanzamiento de WebDriver IO en 2011 y otros proyectos como Appium que aplican el mismo principio al espacio móvil.
Luego ocurrió algo bastante interesante. La web cambió mucho y también la forma en que se construyen las aplicaciones web. Lo que solía ser un servidor estático que entregaba sitios web estáticos se ha convertido en una aplicación web cada vez más dinámica y pesada en JavaScript que utiliza frameworks como React, Vue, Angular o Svelte. Esto cambió drásticamente muchos de los requisitos que las personas tenían al probar aplicaciones. De repente, el front-end y el back-end se volvieron más independientes y las personas realmente querían centrarse en probar solo la aplicación front-end en lugar de implementar todo el stack. Con el desarrollo continuo de más API web disponibles en el navegador, las personas tenían cada vez más casos de uso para probar. Muchos de estos casos de uso no estaban realmente en foco cuando se desarrolló WebDriver o SitAnywhere. Afortunadamente, durante esos tiempos, contábamos con empresas como Cypress que intervinieron y cubrieron las necesidades de los desarrolladores de una manera extraordinaria. Intentaron cerrar las brechas, al igual que muchas otras herramientas que comenzaron a aparecer en el ecosistema. Durante todos estos desarrollos, el estándar que se suponía que resolvería estos problemas se finalizó y se convirtió en un estándar recomendado. Sin embargo, si bien te permitía ejecutar automatización en todos los navegadores, su diseño original ya estaba desactualizado y estaba claro que no resolvería los problemas que los desarrolladores tienen al construir aplicaciones web modernas hoy en día. Por lo tanto, casi al mismo tiempo, se inició un nuevo esfuerzo para desarrollar un nuevo protocolo con las experiencias y los aprendizajes que se obtuvieron al crear el primero y los nuevos requisitos que los desarrolladores tienen al construir aplicaciones web modernas hoy en día. Si observamos el ecosistema, podemos agrupar las herramientas en dos categorías. Por un lado, tenemos las herramientas más convencionales como Selenium o web.io, y por otro lado, las llamadas herramientas no estándar. Ambos grupos tienen características interesantes. Comenzando con las convencionales, como puedes esperar, todas utilizan el protocolo WebDriver y, por lo tanto, te permiten realizar verdadera automatización en varios navegadores. Cada comando que se puede ejecutar en WebDriver se prueba en todos los navegadores, al igual que cualquier otro estándar que existe en la web. Sin embargo, debido a la forma en que se construyen algunos frameworks front-end, aún pueden generar algunas incompatibilidades al probar aplicaciones web. Como diseño de este protocolo, que originalmente debía hacer todo lo que un usuario podría hacer, no es muy adecuado para los desarrolladores que les gusta inspeccionar todas las áreas de la aplicación. Estas herramientas no son muy populares entre los desarrolladores y son más utilizadas por los profesionales de QA. Sin embargo, muchas de ellas son proyectos de código abierto con una larga historia y una gran comunidad, como ReptiveIO, que forma parte de la OpenJS Foundation junto con NodeJS, Mocha y WebPack, y tenemos Selenium, que es un proyecto de la Software Freedom Conservancy.
Por otro lado, tenemos las herramientas no estándar, que tienen sus propias formas de automatizar el navegador y sus propias ventajas y desventajas en comparación con las demás. Estos enfoques personalizados suelen basarse en alguna forma de emulación de JavaScript o mediante el uso de API del navegador, lo que las limita a un navegador específico pero les proporciona capacidades que no tendrías con WebDriver y, por lo tanto, resulta mucho más interesante para los desarrolladores que les gusta inspeccionar aplicaciones web, la red y el DOM, entre otras cosas. Es interesante destacar que todos estos proyectos son financiados por empresas y varias personas trabajan en ellos a tiempo completo. Si observamos todos estos proyectos juntos, veremos que tenemos herramientas como Cypress y Taskerfee que utilizan API web para la automatización, tenemos Puppeteer y Playwise que se basan en API nativas del navegador, y por último, tenemos Selenium, WebDriver.io y muchas otras herramientas que se basan en el protocolo WebDriver. Vale la pena señalar que algunas herramientas como Cypress o WebDriver.io realmente utilizan una combinación de dos enfoques para algunas capacidades de automatización.
3. Automatización de Navegadores con Javascript y Web APIs
WebDriver.io utiliza las APIs del navegador para pruebas de rendimiento e integración en Google Lighthouse. Hay tres enfoques comunes: Javascript, APIs del navegador y controlador del navegador. Javascript y las APIs web son la primera generación de automatización de navegadores, que se remonta a Selenium. Ofrece un control total sobre el entorno de ejecución pero tiene limitaciones. Se requieren soluciones alternativas para ciertas tareas como tomar capturas de pantalla.
4. Enfoques en Automatización con Javascript
Cuando se utiliza la automatización con Javascript como motor, existen dos enfoques comunes: Cypress y TestCafe. Cypress ejecuta la aplicación en un iframe y utiliza un ejecutor de pruebas en el marco principal para acceder al contexto de ejecución. TestCafe utiliza un proxy para inyectar su propio Javascript en la página HTML. Las APIs del navegador, la segunda generación de automatización de navegadores, han evolucionado para permitir una mejor introspección del comportamiento del navegador. Sin embargo, no están bien documentadas y varían entre los navegadores. El protocolo WebCounter combina los enfoques anteriores y es un estándar web desarrollado por todos los proveedores de navegadores.
Las APIs del navegador son, diría yo, la segunda generación de automatización de navegadores porque originalmente se utilizaban en el proyecto WebDriver para automatizar navegadores. En ese entonces, era común abusar de las extensiones del navegador para desencadenar ciertos eventos en el navegador. Y otros navegadores como Internet Explorer se automatizaban mediante una interfaz común nativa que Microsoft proporcionaba en los sistemas operativos Windows en ese entonces. Hoy en día, los proveedores de navegadores han evolucionado y los navegadores son mucho más capaces de inspeccionar lo que sucede en el navegador. Y vemos que muchas de esas capacidades se utilizan no solo en el espacio de automatización, sino también para depurar el navegador a través de herramientas como las Chrome DevTools.
Nuevamente, el problema con estas APIs del navegador es que funcionan de manera muy diferente y no están muy bien documentadas fuera de los equipos de navegadores. Y en realidad cambian mucho de una versión a otra. Piensa en ello como si tuvieras tres amigos navegadores que te ofrecen ayuda, pero todos hablan un idioma diferente, siendo uno de ellos Zafari, a quien no le gusta escucharte y siempre lleva auriculares. Para completar todas las tareas con los amigos navegadores, tendrías que entender y hablar todos los idiomas, por eso herramientas como Puppeteer o frameworks que se basan en Puppeteer generalmente solo pueden automatizar un tipo de navegador. En este caso, uno basado en Chromium. Afortunadamente, vemos que los proveedores de navegadores comienzan a unir fuerzas para hablar un lenguaje más similar, por eso vemos, por ejemplo, el soporte de Puppeteer en Firefox Nightly en estos días. Y por otro lado, los equipos de navegadores antiguos implementan ajustes personalizados en los motores de navegadores para permitirte realizar el mismo tipo de comunicación entre todos estos navegadores.
Por último, tenemos el protocolo WebCounter, que yo diría que es la tercera generación ya que combina realmente los dos enfoques anteriores para garantizar una experiencia de automatización consistente en todos los navegadores. Es un estándar web, lo que significa que es un protocolo desarrollado activamente por todos los proveedores de navegadores. Entonces, si nos reunimos como grupo de trabajo, tenemos personas de Microsoft, de Google, de Apple en una mesa discutiendo sobre ese estándar. Todos los cambios en ese protocolo se prueban, al igual que todos los estándares web. Entonces, si agregamos un comando, ese comando se prueba en todos los navegadores y se ejecuta continuamente para verificar que seamos confiables en todos los navegadores. Pero como mencioné antes muchas veces, el diseño original de ese protocolo no cumplió con los requisitos de pruebas de las aplicaciones web modernas de hoy en día. La forma en que funciona el protocolo WebCounter es que para cada navegador hay algún tipo de controlador que puede traducir comandos bien definidos, como hacer clic en un elemento, en un comando de automatización que el navegador comprende. El protocolo a menudo se menciona y se considera muy lento y desactualizado. Una de las razones es, por ejemplo, que este paso de traducción del controlador requiere una solicitud adicional. Por lo tanto, puedes pensar en el protocolo WebCounter como si fueras un desarrollador o una
5. Nuevo Estándar para la Automatización del Navegador
Debido a COVID, tienes que trabajar desde casa sin contacto directo con la fábrica. Un asistente te ayuda a dar comandos, pero las limitaciones de este enfoque son problemáticas para probar aplicaciones web modernas. El grupo de trabajo W3 está desarrollando un estándar actualizado para la automatización del navegador, que permite enviar múltiples comandos a múltiples actores y proporciona introspección en la red, el DOM y la consola. La compatibilidad con versiones anteriores sigue siendo importante.
6. El Futuro de la Automatización del Navegador
El futuro de la automatización del navegador traerá cambios significativos en la forma en que se ejecutan las pruebas. El nuevo protocolo WebDriver permitirá enviar y recibir miles de comandos y mensajes simultáneamente, lo que plantea desafíos para los proveedores de navegadores y la nube. Los modelos de ejecución cambiarán, con las pruebas acercándose al navegador. La prueba funcional por sí sola ya no será la única medida de la calidad de la aplicación. Los proveedores estarán involucrados en todo el ciclo de vida del desarrollo de software, capturando información de diversas fuentes. Continuarán surgiendo nuevos tipos de pruebas, como las pruebas de rendimiento y accesibilidad. Si bien el futuro sigue siendo incierto, el protocolo WebDriver y los frameworks como Cypress y Playwright ofrecen desarrollos emocionantes. Los estándares son cruciales para mejorar la calidad web.
7. Nuevas oportunidades con el protocolo WebDriver
El nuevo protocolo WebDriver combina lo mejor de los tres enfoques y brinda oportunidades para probar y automatizar aplicaciones web. Los estándares web se envían con extensiones de WebDriver, como la API de autenticación web, cambios en HTML para la zona horaria y otras API como sensor, informes del navegador y permisos. El proceso de creación de estándares es lento pero se está desarrollando más rápido. Las soluciones de automatización basadas en protocolos propietarios son limitadas y las herramientas de prueba deben basarse en estándares. Gracias por la oportunidad de hablar y por escuchar.
Por un lado, tenemos este nuevo protocolo WebDriver en desarrollo que brinda muchas más oportunidades. Realmente combina lo mejor de los tres enfoques y crea enormes posibilidades para que los implementadores construyan herramientas que puedan probar y automatizar eficazmente aplicaciones web. También es muy emocionante ver que cada vez más estándares web se envían con extensiones de WebDriver. Tenemos, por ejemplo, la API de autenticación web que te permite crear autenticadores virtuales con WebDriver. Muy recientemente, hemos visto cambios en HTML que han provocado la creación de un nuevo comando de WebDriver para cambiar la zona horaria. Y tenemos muchas más API, como la API de sensor, las API de informes del navegador y las API de permisos que ya tienen extensiones de WebDriver. Dicho esto, crear cualquier forma de estándares generalmente es un proceso muy lento. Necesitas que la gente se involucre. Debes asegurarte de que lo que estandarices tenga sentido para todos los usuarios. Y debes escribir la especificación. Por lo tanto, estos cambios no ocurrirán de la noche a la mañana. Es realmente bueno ver, sin embargo, que todos estos desarrollos en el espacio de las herramientas y estándares están teniendo lugar y se están acelerando cada vez más. Estamos al final de mi charla, y quería terminar con la siguiente cita de Maya y James, quienes son desarrolladores en Mozilla. Ellos dicen que una solución de automatización basada en un protocolo propietario siempre estará limitada en la cantidad de navegadores que puede admitir. El éxito de la web se basa en estándares de múltiples proveedores. Es importante que las herramientas de prueba se basen también en estándares, para que las pruebas funcionen en todos los navegadores y dispositivos donde funciona la web. Con eso, muchas gracias por darme esta oportunidad de hablar, y gracias a todos por escuchar. Hola, Christian. Gracias nuevamente por tu charla. Estuvo muy buena. Gracias. ¿Qué opinas del resultado de las encuestas? Quiero decir, esperaba esa respuesta. Cada vez que tienes una pregunta técnica, depende de la forma correcta de proceder. Y para responder, en mi opinión, depende. Supongo que hay muchas formas de automatizar los navegadores. En este momento, las más populares suelen ser tres, que expliqué en mi charla. Sí. Sí, como dije, depende. Esta es probablemente una respuesta muy utilizada.
QnA
Preguntas sobre Automatización de Bajo Código y APIs del Navegador
Hablando de preguntas, vi que ya tenemos algunas preguntas en el canal de preguntas y respuestas. Triderman preguntó sobre plataformas de automatización de bajo código como Tosca. Recientemente he estado explorando soluciones de bajo código y creo que es una excelente manera de introducir a más personas a las pruebas. Sudharsan preguntó sobre cómo ejecutar pruebas de navegador en modo sin cabeza en tiempos de ejecución en la nube. El corredor de bolsa preguntó sobre el futuro de las herramientas nativas y las APIs del navegador. Guy cuestionó si las herramientas pueden entender inteligentemente las SPAs. La automatización de los navegadores es asíncrona y esperar a que existan elementos es crucial. Las herramientas que simplifican este proceso tendrán éxito como marcos de automatización.
Desarrollo, Estandarización y Futuro
Habrá un desarrollo continuo en todos los marcos. Los proveedores de SmartTV y los navegadores más oscuros no forman parte de los esfuerzos actuales de estandarización. El enfoque está en los protocolos web, con intentos pasados de estandarización móvil. Lograr que los proveedores acuerden estándares es un desafío. El futuro podría traer estandarización en el espacio de IoT. La extensión de autenticación web puede no admitir la autenticación básica HTTP, pero está en el plan de trabajo. Otras preguntas pueden ser abordadas en la sala de discusión. Gracias por unirse a nosotros.