Un recorrido por las abrumadoras formas de automatizar navegadores. Únete a Michael en un recorrido para ver qué sucede detrás de escena de "await page.goto('https://example.com');" y otros. Descubre los pros y los contras de cada una de las tres formas de automatización de navegadores.
Entiende por qué estamos agregando una cuarta: WebDriver BiDi.
This talk has been presented at JSNation 2023, check out the latest edition of this JavaScript Conference.
FAQ
La automatización del navegador es un proceso que automatiza las interacciones del usuario con un navegador web, simulando las acciones de un usuario real. Funciona almacenando estas interacciones, como código fuente, y luego reproduciéndolas para ejecutar pruebas, extraer datos o manipular elementos de la página.
Los principales beneficios incluyen la reducción de los costos continuos de prueba, la mejora de la precisión en la detección de errores y deficiencias en aplicaciones, y la posibilidad de realizar pruebas repetitivas sin intervención manual, lo que permite a los desarrolladores centrarse en tareas más complejas.
Herramientas como Selenium, Nightwatch.js y WebDriverIO utilizan el Protocolo WebDriver para automatizar navegadores, permitiendo la ejecución de pruebas a través de comandos que se traducen en acciones dentro del navegador.
WebDriver Bidi es un nuevo estándar para la automatización de navegadores que combina los beneficios de WebDriver y CDP, ofreciendo controles de bajo nivel y comunicación bidireccional. Proporciona soporte multi-navegador y está diseñado específicamente para pruebas, mejorando la eficiencia y la capacidad de realizar pruebas más complejas.
CDP, usado por herramientas como Puppeteer, ofrece un control de bajo nivel y es rápido ya que comunica directamente con navegadores basados en Chromium sin necesidad de un controlador. WebDriver, aunque es más lento y menos detallado en control, es un estándar con soporte multi-navegador. Ambos tienen ventajas únicas según el contexto de uso.
Puppeteer es una biblioteca de automatización de Chrome que utiliza internamente el protocolo Chrome DevTools (CDP) para automatizar navegadores basados en Chromium. Permite enviar comandos directamente al navegador a través de WebSockets, facilitando la automatización de pruebas y otras tareas de automatización del navegador.
Con WebDriver Bidi, herramientas como Selenium y Puppeteer pueden comenzar a utilizar controles bidireccionales, permitiendo una integración más eficiente y avanzada con el navegador. Esto reduce la necesidad de utilizar directamente CDP y aprovecha las ventajas de una comunicación más fluida y controles más detallados.
Esta charla discute técnicas de automatización de navegadores, incluida la introducción de un nuevo controlador web. Cubre la historia de la automatización de navegadores, diferentes técnicas para automatizar navegadores y el uso de API web y extensiones de navegador. La charla también explica cómo las herramientas de automatización se comunican con los controladores de navegador y los desafíos de esperar a que los elementos aparezcan en la pantalla. Destaca las diferencias entre el protocolo WebDriver y el protocolo Chrome DevTools, e introduce el proyecto WebDriver Bidirection que tiene como objetivo combinar las mejores partes de ambos protocolos. Por último, menciona el soporte de WebDriver Bidi para la supervisión de la consola e introduce WebDriver ByteEye como una opción estable de automatización.
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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
Short description:
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.
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
La web ha evolucionado. Finalmente, también lo ha hecho el testing. Cypress es una herramienta de testing moderna que responde a las necesidades de testing de las aplicaciones web modernas. Ha ganado mucha popularidad en los últimos años, obteniendo reconocimiento a nivel mundial. Si has estado esperando aprender Cypress, ¡no esperes más! Filip Hric te guiará a través de los primeros pasos sobre cómo empezar a usar Cypress y configurar tu propio proyecto. La buena noticia es que aprender Cypress es increíblemente fácil. Escribirás tu primer test en poco tiempo y luego descubrirás cómo escribir un test de extremo a extremo completo para una aplicación web moderna. Aprenderás conceptos fundamentales como la capacidad de reintentar. Descubre cómo trabajar e interactuar con tu aplicación y aprende cómo combinar pruebas de API y de UI. A lo largo de todo este masterclass, escribiremos código y realizaremos ejercicios prácticos. Saldrás con una experiencia práctica que podrás aplicar a tu propio proyecto.
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman. Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend. Nivel de la masterclass: Intermedio
Este masterclass te enseñará los conceptos básicos de cómo escribir pruebas de extremo a extremo utilizando Cypress Test Runner. Cubriremos la escritura de pruebas, abarcando todas las características de la aplicación, estructurando las pruebas, interceptando solicitudes de red y configurando los datos del backend. Cualquier persona que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir el masterclass.
TestJS Summit 2021
JSNation 2022
React Summit 2023
React Summit US 2023
Comments