La Evolución de la Automatización del Navegador

por invitarme a inaugurar la conferencia. Estoy muy emocionado por todas las excelentes charlas de expertos de todo el mundo que veremos en los próximos dos días. Y estoy muy contento de que eventos tan geniales sigan teniendo lugar a pesar de la difícil situación global en la que nos encontramos. Me gustaría dedicar los próximos 25 minutos para hablar un poco sobre cómo la automatización del navegador ha evolucionado en la última década aproximadamente, y espero que esto brinde un poco más de contexto cuando escuchen sobre herramientas de automatización en las próximas sesiones. Pero antes de comenzar, permítanme presentarme. Soy Christian, trabajo en la Oficina de Programas de Código Abierto en Sauce Labs. Y la mayoría de las personas probablemente me conozcan como el mantenedor de Web.IO, un proyecto que me entusiasmó hace muchos años sobre las pruebas automatizadas y la automatización del navegador. Y mantener el proyecto realmente me enseñó muchas cosas sobre cómo funcionan los navegadores en general y cómo se desarrollan el código abierto y los estándares. Y estos son todos temas en los que tengo la suerte de trabajar a tiempo completo en estos días. La razón por la que quería dar esta charla es porque veo muchas ideas erróneas sobre cómo funciona realmente la automatización del navegador. Es un desafío interesante, especialmente para proveedores y vendedores en la nube, porque como usuario no hay mucha diferenciación entre tu marco de automatización y la automatización que realmente ocurre en el navegador. Entonces, por ejemplo, si tu clic no se realiza, aunque el script de prueba pase sin errores o si el script no puede encontrar un elemento, aunque claramente veas que el elemento está ahí cuando lo verificas tú mismo, las personas tienden a culpar primero a los frameworks y luego en algún momento al proveedor de la nube. Mientras que en realidad, hay muchas sutilezas y procesos responsables de hacer que ese clic ocurra en primer lugar, tal vez en una máquina virtual que está a kilómetros y kilómetros de la máquina que realmente ejecuta tu prueba. Entonces, veamos cómo un comando de clic en el marco de trabajo termina siendo un evento de clic en el navegador y para hacerlo, me gustaría comenzar con un pequeño resumen. La automatización del navegador ha existido durante más de una década y ha habido algunos desarrollos e influencias interesantes a lo largo de los años, especialmente con la web cambiando desde lo que era hace 15 años hasta lo que es hoy. Entonces, repasemos lo que ha sucedido hasta ahora y cómo llegamos a donde estamos ahora. Todo comenzó en 2004, con alguien llamado Jason Huggins, que necesitaba probar una herramienta de gastos en ThoughtWorks para asegurarse de que funcionara en IE y Firefox en ese momento. Llamó a esa herramienta Selenium, y probablemente sea un proyecto que todos ustedes ya conocen. Un año después, otro actor entra en escena, afirmando haber construido una mejor herramienta, que se llamaba WebDriver. Ese tipo era Simon Stewart. Ambas herramientas ganaron cada vez más popularidad a lo largo de los años a medida que la automatización del navegador se convirtió en algo para probar aplicaciones web. Entonces, en algún momento, Jason pensó que sería una buena idea crear una empresa. Esa empresa se llamaba Source Labs. Era evidente que ambas herramientas, el proyecto WebDriver y el proyecto Selenium, eran geniales, pero tenían sus ciertas limitaciones en áreas específicas. Selenium, que en ese momento se ejecutaba en el navegador, tenía problemas con las políticas de cruce de regiones y la automatización en general alrededor del navegador. WebDriver tenía otras limitaciones cuando se trataba de automatizar ciertos elementos. Jason y Simon fusionaron los proyectos en una fuerza conjunta para superar esta limitación y proporcionar la mejor experiencia posible en ese momento. A lo largo de los años, estos frameworks ganaron cada vez más popularidad hasta el punto en que las personas tenían una idea clave de cómo funciona la automatización. Y así, se formó un grupo de trabajo en el W3C para estandarizar este proceso.

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.

Cypress necesita utilizar las APIs del navegador, por ejemplo, para tomar capturas de pantalla del navegador. Por otro lado, tenemos WebDriver.io que utiliza las APIs del navegador para sus características de pruebas de rendimiento o integración en Google Lighthouse. Echemos un vistazo más de cerca para ver cómo se pueden automatizar los navegadores en general en la actualidad. Como mencioné antes, generalmente hay tres enfoques comunes. Uno a través de Javascript, otro a través de las APIs del navegador y el último a través de un controlador del navegador. Ordenaría el uso de Javascript y las APIs web como enfoque de automatización como la primera generación de automatización de navegadores. Aunque herramientas más novedosas como Cypress o Taskerface utilizan este enfoque, en realidad ha estado presente desde la creación de Selenium, que era como Cypress, un ejecutor de pruebas dentro del navegador. De hecho, para algunos comandos de automatización, como averiguar si un elemento es visible, Selenium todavía utiliza un Javascript que inyecta en la página. Esto se debe a que es casi imposible definir un estado visible en el contexto de un estándar web como WebDriver. La ventaja de este enfoque es que tienes un control total sobre el entorno de ejecución de tu aplicación y te permite ejecutar los comandos de manera rápida y confiable. Sin embargo, solo puedes hacer tanto como Javascript y especialmente las APIs web te permiten hacer, que es mucho, pero necesitas soluciones alternativas para ciertas situaciones como, por ejemplo, tomar

las capturas de pantalla. Si observamos cómo funciona cuando se utiliza la automatización con Javascript como motor, generalmente hay dos enfoques comunes que se pueden seguir. Uno utilizado por Cypress donde se ejecuta la aplicación en una prueba en un iframe y se tiene un ejecutor de pruebas en el marco principal que accede al contexto de ejecución. El navegador es prácticamente un ejecutor de pruebas que renderiza la aplicación en la prueba en un iframe. El ejecutor de pruebas puede intercambiar mensajes o acceder al iframe con Javascript directamente. TestCafe aborda esto de manera un poco diferente. Utilizan un proxy para redirigir todas las solicitudes que provienen de la página e inyectar así su propio Javascript en la página HTML. Nuevamente, la limitación general de este enfoque es que estás atrapado en el sandbox de Javascript y no tienes acceso fuera de él. Por lo tanto, las soluciones alternativas que utilizan herramientas como Cypress o TestCafe son a través de las APIs del navegador.

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

como autor de pruebas, eres como el administrador de una fábrica de navegadores. Pero, por supuesto, debido a COVID, tienes que trabajar desde casa. Y en este caso, tu hogar no tiene teléfono ni internet, por lo que no puedes comunicarte directamente con tu fábrica. Necesitas tener un asistente para dar comandos en esa fábrica. Entonces, el asistente viene a ti, te pide un comando, luego el asistente va a la fábrica, ejecuta el comando y en algún momento regresa con el resultado. Esto a veces puede llevar hasta 200 milisegundos, si no más, especialmente si se ejecuta en la nube. En un día ocupado, a veces ejecutas miles de comandos en una sola prueba. Obviamente, esta no es una forma efectiva de administrar una fábrica. Si bien una transacción única es lenta, este enfoque, sin embargo, tiene la ventaja de ser realmente escalable. Tenemos clientes que ejecutan tubos de pruebas eficientes, hasta mil pruebas en paralelo, lo que puede reducir enormemente el tiempo de ejecución de todo un tubo de pruebas, mientras que una prueba única aún puede ser lenta. Otra ventaja es que puedes automatizar no solo fábricas con navegadores, sino literalmente todo tipo de fábricas, ya sea una fábrica móvil o una fábrica de IoT. Si ejecutas, digamos, una fábrica de navegadores, tienes un asistente que comprende el funcionamiento interno de un navegador y puede ayudarte a hacer que ese comando sea relevante para ti. Si tienes una fábrica móvil, tienes un asistente que comprende iOS o Android y puede ejecutar tus comandos allí. Entonces, esta idea de tener este traductor para ejecutar un comando trivial, como hacer clic en un botón en un agente de usuario complejo, funciona bastante bien. Como mencioné antes, tu asistente aquí realmente puede hacer todo tipo de comandos si comprende la fábrica. Pero la limitación es que siempre tiene que ir a la fábrica, ejecutar el comando y regresar. Estas limitaciones son muy problemáticas para probar aplicaciones web modernas, donde realmente necesitas introspeccionar toda la fábrica en sí. Afortunadamente, el grupo de trabajo W3 ha iniciado un nuevo esfuerzo para desarrollar un estándar actualizado que supere los problemas que vemos en la automatización de navegadores hoy en día. Basado en este pequeño experimento mental que acabamos de hacer con este sistema, este nuevo mundo de la automatización del navegador se vería así. Serías una especie de comandante que supervisaría no solo una sola fábrica, sino todos los demás dominios de tu ecosistema. En lugar de dar un comando a la vez, puedes dar múltiples comandos a múltiples actores al mismo tiempo mientras escuchas diferentes entradas de ellos. Te convierte en una especie de dios de la automatización, por así decirlo. Viene con muchas características interesantes. Por un lado, intenta abordar las capacidades que los desarrolladores tienen hoy en día y que desean tener introspección en la red, el DOM y la consola. Es probable que venga con primitivas para modificar los datos de la red sin tener que usar un proxy o permitirá introspeccionar el DOM para manejar elementos sin problemas. Además de eso, te proporcionará suficiente acceso para que los implementadores puedan ser muy creativos al construir marcos de pruebas Por ejemplo, hay un plan de script de inicio que te permite ejecutar ese tipo de script antes de que se cargue tu aplicación en el contexto de ejecución. Y eso te permite parchear API o instalar tus propias extensiones de automatización. Pero también te brinda acceso hasta cierto punto, también te brinda acceso a las API del navegador para controlar el navegador utilizando capacidades nativas. Y así finalmente puedes hablar con tu amigo Safari. Pero como todos los estándares web que tenemos hasta ahora

Por ahora, la compatibilidad con versiones anteriores es importante. Por lo tanto, podrás seguir probando navegadores heredados y navegadores de solo una versión. Dicho esto, este protocolo está en desarrollo. Y como todos los estándares web, el feedback es importante. Así que si automatizas un navegador, lo cual creo que todos ustedes hacen hasta cierto punto, acérquense y brinden su opinión. Esto es realmente importante para que el nuevo diseño del protocolo cubra los casos de uso y requisitos de todos. Otro dato interesante aquí es que con este esfuerzo, cambiará bastante la forma en que se ejecutan las pruebas en el futuro. En lugar de enviar un comando y recibir una respuesta, podrás enviar miles de comandos y recibir miles de mensajes al mismo tiempo. Por lo tanto, la cantidad de intercambio de datos aumentará considerablemente, lo cual es particularmente interesante y problemático para los proveedores de navegadores como Salesforce, donde el modelo de negocio actual es enviar un comando de navegador a través de Internet a una máquina virtual en la nube y recibir una respuesta. Con el nuevo protocolo WebDriver, esto probablemente ya no funcionará. Si intentaras ejecutar esto a la misma escala con la misma cantidad de navegadores, técnicamente podrías saturar tu propio sistema CI/CD. Por lo tanto, esos proveedores de navegadores o proveedores de la nube necesitan encontrar una solución para superar este problema. Y ha habido algunos desarrollos interesantes en este mercado. Por un lado, es probable que veamos un cambio en el modelo de ejecución. Ya no enviaremos un solo comando a través de Internet, porque tu prueba se encuentra en un lugar diferente del mundo que el navegador. Estos comandos o componentes se moverán juntos. Es probable que el proveedor de navegadores te pida que cargues la prueba en la nube o te proporcione una forma de ejecutar la prueba con el navegador en tu propia infraestructura. Otra tendencia que he visto es que la prueba funcional por sí sola no será la única forma en que mediremos la calidad de tu aplicación. Los proveedores estarán más presentes a lo largo de todo el ciclo de vida del desarrollo de software de la aplicación y te acompañarán en el proceso de desarrollo, prueba y lanzamiento. Se capturará información de todos los lados del espectro y se utilizará para indicar qué está mal en tu aplicación. Por último, con el aumento de todas estas señales de calidad, también veremos un aumento en nuevos tipos de pruebas. En los últimos años, ya hemos visto desarrollos en ese espacio. Por ejemplo, ha habido desarrollos y pruebas de rendimiento con WebDriver. Este año, es probable que veamos más herramientas de pruebas de accesibilidad y habrá más tipos de pruebas diferentes como ese. Habrá muchos desarrollos interesantes y aunque el protocolo nos dará mucho trabajo como proveedor de navegadores, también ofrece una tremenda cantidad de oportunidades para construir las herramientas que necesitamos para lanzar esa aplicación en la web. Entonces, ¿qué sigue? ¿Cómo será el futuro de la automatización del navegador? Honestamente, no puedo decirlo con certeza. Tampoco te recomendaré un framework sobre otro. Estoy emocionado por todos estos desarrollos que tenemos en el espacio. Y aunque me gustaría que el protocolo WebDriver como estándar tenga éxito, al mismo tiempo apoyo herramientas como Cypress o Playwright que realmente empujan los límites de la automatización y brindan mucho valor para el desarrollador. Y honestamente, sin estos frameworks, no veríamos ese tipo de desarrollo que tenemos en el espacio de los estándares en este momento. Dicho esto, si quieres mejorar la calidad de la web, no puedes prescindir de los estándares, por eso también estoy emocionado por los desarrollos que ocurren en ese espacio.

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.

para muchas preguntas. Simplemente funciona. Hablando de preguntas, vi que ya tenemos algunas preguntas en el canal de preguntas y respuestas. Triderman, lamento mucho si pronuncio esto mal, preguntó, ¿qué piensas sobre las plataformas de automatización de bajo código como Tosca? Sí. Recientemente he estado explorando mucho las soluciones de bajo código, ya que se vuelve cada vez más interesante. Y creo que es una excelente manera de introducir a más personas a las pruebas. Y estas herramientas también se están volviendo cada vez más sofisticadas, proporcionando soluciones valiosas para las personas que no saben programar. Y eso está totalmente bien. Queremos que esas personas también puedan probar software. Sí. En mi experiencia, también es invaluable contar con personas que conocen el producto y pueden ayudar a escribir las pruebas. De acuerdo. Sí. Sudharsan, nuevamente, lamento mucho si estoy maltratando los nombres, escribió: Prefiero ejecutar pruebas de navegador en modo sin cabeza en tiempos de ejecución en la nube, como Lambda/Google Functions. Me gustaría saber qué marco tiene soporte nativo. ¿Sabes algo al respecto, Christian? He estado experimentando con eso en el Proyecto de Desarrollo Web para poder ejecutar un montón de funciones Lambda en la nube y escalar a miles sin tocar tu propia CPU. Es algo realmente interesante y creo que es algo que podríamos explorar para avanzar al menos para las personas que buscan una solución confiable para probar en un navegador que se ejecuta eficientemente en un contenedor Docker. Así que veamos qué nos depara el futuro. Sí, nunca he hecho algo así, pero esperemos que el futuro traiga mucho más soporte para esto. El corredor de bolsa preguntó cuánto tiempo pasará hasta que las herramientas nativas sean eclipsadas y las APIs del navegador dependan de herramientas y de qué manera. No estoy seguro de si entendí bien la pregunta, ¿cuánto tiempo pasará hasta que las herramientas nativas? Creo que las APIs del navegador seguirán desarrollándose, ya que suelen ser una buena forma de ayudar a las personas a depurar el navegador también. Así que definitivamente veremos mucho desarrollo en ese sentido en todos los navegadores y motores de navegadores. Sí, supongo que tal vez la pregunta se refería al uso o algo así, pero tal vez el corredor de bolsa pueda aclararlo si esto no respondió a su pregunta. Guy dijo que mi experiencia con estos marcos es esperar mucho a que x exista. ¿Existe un futuro en el que estas herramientas puedan entender inteligentemente las SPAs? Sí, yo también he tenido esa experiencia muchas veces. Sí, creo que es una buena pregunta. La cosa sobre automatizar un navegador es que los navegadores en sí mismos, como software, son realmente asíncronos. La idea de un navegador es realmente asincrónica. Y esos métodos donde tienes que esperar a que exista un elemento es algo que necesitas hacer para que esta automatización del navegador funcione. Hay herramientas que intentan ayudarte con eso. Y creo que las herramientas que son realmente buenas en esto tendrán éxito como marcos de automatización, porque es realmente difícil para las personas que no desarrollan navegadores entender eso. Y debemos hacer esto lo más simple posible.

Es posible. Y definitivamente habrá un desarrollo como este. Lo vemos en todos los marcos en este momento. Creo que este tipo de desarrollo también continuará. Sí. Ok. Philly Fala preguntó, ¿los proveedores de SmartTV y otros navegadores más oscuros también forman parte de esta estandarización? No. Actualmente, los protocolos web se centran en la web. Ha habido algunos esfuerzos en el pasado para crear algún tipo de estándar móvil en torno a la automatización. El problema es que necesitamos que estos proveedores se sumen y acuerden ese tipo de estándares. Y mientras eso no suceda, será difícil crear un estándar como este para la web. Todos hemos acordado, todos los proveedores de navegadores han acordado trabajar en ese tipo de estándares. Me encantaría ver eso también en el espacio de IoT. Y veremos qué nos depara el futuro. Ok. Creo que tenemos tiempo para una última pregunta. Joey Halfrich preguntó, ¿permitirá la extensión de autenticación web la autenticación básica HTTP? Lo usamos para mantener alejados a los bots de los sitios en desarrollo, pero tenemos que desactivarlo para ejecutar pruebas. Desafortunadamente, no he investigado mucho sobre esa extensión para desarrolladores web. No estoy seguro. No creo que permita la autenticación básica, pero es algo que está en el plan de trabajo de la extensión para desarrolladores web. Ok. Creo que todas las demás preguntas pueden ser respondidas en la sala de discusión en spatial.chat, donde Christian se unirá a ustedes en breve. Muchas gracias de nuevo por unirse a nosotros. Fue un placer. Gracias.