Tres formas de automatizar tu navegador, y por qué estamos agregando una cuarta: WebDriver BiDi

Rate this content
Bookmark

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.

19 min
05 Jun, 2023

Video Summary and Transcription

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.

Available in English

1. Introducción a la Automatización del Navegador

Short description:

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.