Cómo elegir una herramienta de automatización

Rate this content
Bookmark

¿Cuáles son los aspectos que debes tener en cuenta al elegir un marco de automatización? Algunas diferencias principales entre los marcos disponibles.

Explica las principales diferencias entre los marcos más conocidos para la automatización: Selenium, Cypress, Playwright y Robot Framework. Aspectos positivos y negativos de los marcos. Dependiendo de las necesidades del proyecto en el que trabajas, ¿cuál es el mejor marco para usar? Breve conversación sobre cómo los marcos se integran con algunas herramientas de gestión de pruebas.

21 min
03 Nov, 2022

Video Summary and Transcription

Soy Lia, una ingeniera de software en Nocare, y voy a mostrarte un proceso para elegir una herramienta de automatización. Compararé tres marcos y discutiré otras opciones de integración. Selenium es un marco bien establecido con una gran comunidad, pero requiere integraciones de terceros para ciertos tipos de pruebas. Cypress es una herramienta todo en uno que admite pruebas unitarias, pero solo funciona con JavaScript y carece de capacidades de pruebas paralelas. Playwright es un marco más nuevo que es más completo y admite pruebas paralelas, pero tiene una comunidad más pequeña y una documentación menos madura. Si quieres un marco que lo haga todo, elige Playwright. La documentación es esencial para recordar tus pensamientos iniciales, mostrar a otros qué se está probando y establecer buenas prácticas. Una vez que tengas tu lista de pruebas, marco elegido y priorizaciones, programa una reunión con la dirección. Presenta tu trabajo con confianza, ya que es el mejor enfoque para el equipo y el producto.

Available in English

1. Choosing an Automation Tool

Short description:

Soy Lia, una ingeniera de software en Nocare, y voy a mostrarles un proceso para elegir una herramienta de automatización. Compararé tres frameworks y discutiré otras opciones de integración. Analizar su aplicación es el primer paso, entender sus puntos débiles y crear una lista de pruebas. Hablen con el equipo de desarrollo para evitar la duplicación de trabajo. Si no tienen pruebas unitarias, consideren implementar pruebas de automatización a lo largo del proceso. Decidan si quieren programar y elijan un lenguaje cómodo. Si no, hay opciones inclusivas como testing y perfecto. Si prefieren programar, compararé Selenium, Cypress y Playwright.

Espero que todos se sientan bien y antes que nada, quiero agradecerles a todos por estar aquí hoy. Soy Lia y les mostraré un proceso que pueden utilizar para elegir una herramienta de automatización. Haré una comparación general de tres frameworks que considero los mejores en este momento, y hablaré un poco sobre otras herramientas que pueden integrar en su proceso de automatización.

Así que una breve introducción sobre quién soy. Soy una ingeniera de software en Nocare. Mi enfoque principal es la automatización de pruebas. Y ahora vamos a sumergirnos en esto. Este es un proceso de tres pasos, como todos los buenos, por supuesto. Pero cada paso requerirá atención y trabajo. Así que sigamos adelante y sumerjámonos en la primera fase, que es analizar.

Analizar significa responder algunas preguntas. Y la primera no es realmente una pregunta. Es entender su aplicación. Mírenla y sean realmente críticos al respecto. Traten de entender cuáles son los puntos débiles, las características que se pueden romper más fácilmente, y traten de pensar en casos extremos en la aplicación. Así que tengan una imagen general de la aplicación que van a probar y hagan una lista. Hagan una lista de las pruebas que quieren o necesitan hacer. En este momento, sería una buena idea hablar con el equipo de desarrollo y tratar de entender cuál es la cobertura de pruebas unitarias que tienen, si es que tienen, y al conocer su cobertura pueden evitar la duplicación de trabajo por su parte.

Y si no tienen pruebas unitarias, es una buena oportunidad para reunirse con ellos y con el equipo de gestión y pensar en una forma de tener cobertura desde el desarrollo hasta la producción. Y esto significa tener pruebas de automatización en todas las partes del proceso. Así que el equipo de desarrollo tendrá pruebas unitarias y ustedes pueden tener pruebas de seguridad, accesibilidad, o cualquier otro tipo que consideren más adecuado. Teniendo esto en cuenta, tendrán que preguntarse si quieren programar o no, y preguntar a su equipo si se sienten cómodos haciéndolo. Y en qué lenguaje se sienten más cómodos trabajando. Así que teniendo esto, terminarán con una lista más o menos como esta, en la que tienen si el equipo de desarrollo tiene pruebas unitarias o no, qué tipo de pruebas van a hacer, y tendrán un lenguaje con el que se sientan más cómodos trabajando, si eligen programar. Así que si no quieren programar, eso no es un problema porque aquí somos inclusivos y tenemos opciones para todos. Y si no quieren programar, les daré dos opciones que conozco, y tengan en cuenta que creo que hay muchas más opciones para ustedes, así que si estas opciones que les voy a dar no se adaptan a sus necesidades, simplemente búsquenlas. Y estamos entrando aquí en la siguiente parte que es buscar, pero antes les voy a hablar sobre testing y perfecto, y estas dos son similares en las cosas que pueden hacer, pero en una explicación rápida, estas dos graban sus pruebas manuales, y por cada acción que realicen en el navegador hacen un bloque. Y cuando terminen tendrán su caso de prueba y su automatización que es un grupo de bloques, al igual que en la programación pueden crear un grupo de bloques que pueden reutilizar entre pruebas, pueden crear carpetas para ejecutar en cada implementación, tienen un grupo completo de opciones que pueden tener al igual que en la programación. Así que si no quieren programar, echen un vistazo a esta herramienta y sumérjanse en ella porque estoy segura de que también tendrán opciones para ustedes. Así que si quieren programar, haré una comparación entre Selenium y Cypress.

2. Comparando Selenium, Cypress y Playwright

Short description:

Selenium es un framework bien establecido con una gran comunidad, pero requiere integraciones de terceros para ciertos tipos de pruebas. No admite pruebas paralelas ni iframes. Cypress es una herramienta todo en uno que admite pruebas unitarias, pero solo funciona con JavaScript y carece de capacidades de pruebas paralelas. Playwright es un framework más nuevo que es más completo y admite pruebas paralelas, pero tiene una comunidad más pequeña y una documentación menos madura.

Selenium y Playwright. Y esto es más o menos lo que van a hacer en la parte de búsqueda con los frameworks que elijan para comparar. Y comenzando con Selenium. Selenium es un framework que ha estado aquí durante mucho tiempo, y esto significa que Selenium tiene una gran comunidad que lo respalda. Y no estarán solos trabajando porque tendrán Stack Overflow para ayudarlos con un gran grupo de personas que pueden ayudarlos. Y en general, es un framework realmente bueno, pero necesitará terceros para trabajar con ciertos tipos de pruebas. Entonces, Selenium automatiza el navegador. Simula una interacción real del navegador, lo que significa que si necesitan hacer pruebas de API, deberán integrarse con un tercero para tener las pruebas de API. Y dado que Selenium no admite por sí mismo pruebas paralelas, deberán integrarse con Selenium Grid y una herramienta de navegadores cruzados para que funcione. Y para mí, las desventajas más importantes de Selenium son que no tiene una herramienta de informes incorporada, por lo que necesitarán un tercero como X-Ray o Test Rail, de los que hablaré un poco al final, para admitir esto. Y no admite iframes o popups. Entonces, si su aplicación depende de iframes de terceros, Selenium no será realmente el framework adecuado. Pero, si esto es algo con lo que pueden vivir sin, Selenium es realmente muy bueno para trabajar con un gran conjunto de pruebas, pero, como les dije, necesitará integraciones de terceros para algunos tipos de pruebas, y esto hará que sea más difícil trabajar al principio. No estoy diciendo que sea imposible porque nada es imposible, pero necesitarán algo de experiencia y conocimiento para comprender cuáles son las soluciones alternativas que deben hacer aquí, ¿de acuerdo? Entonces, es una buena herramienta. Si quieren algo más fácil para comenzar, pasemos a la otra herramienta y comprendamos cuáles son las diferencias aquí. Con Cypress, Cypress es una herramienta todo en uno, lo que significa que el equipo de desarrollo puede hacer pruebas unitarias y ustedes pueden hacer los otros tipos de pruebas en su sitio, y todo el equipo trabaja con el mismo framework, y esto es genial porque pueden ayudarse mutuamente y revisar el código entre ustedes, y es muy completo, tiene un informe incorporado, no necesitan integrarse con terceros aquí, pero la desventaja es que solo funciona con JavaScript y no admite pruebas paralelas y pruebas multitap, lo que significa que si necesitan tener ciertos tipos de configuraciones que deben ejecutarse al mismo tiempo, por ejemplo, si quieren tener un navegador con un dispositivo y varias configuraciones al respecto, deberán ejecutarlos por separado. Entonces, será un tiempo muy largo ejecutar el caso de prueba. Si necesitan tener varios conjuntos de configuraciones aquí, varios entornos ejecutándose al mismo tiempo, deben considerar si Cypress será una buena herramienta para ustedes. Pero para principiantes y para un grupo pequeño o mediano de pruebas, Cypress es realmente bueno. Es una herramienta muy simple de trabajar si trabajan con JavaScript, por supuesto. Es una herramienta muy simple de trabajar y tiene mucha documentación, la comunidad está creciendo, por lo que tendrán ayuda en Stack Overflow para cualquier tipo de datos que necesiten. Pero tiene sus desventajas, al igual que todos los frameworks que encontrarán aquí. Pasando a Playwright, Playwright es un framework bastante nuevo. La primera vez que escuché hablar de él fue aquí en 2020, si no me equivoco, y creo que es el más completo de los tres. Pueden tener todo tipo de pruebas ejecutándose en Playwright, admite pruebas paralelas para que puedan tener varios conjuntos de configuraciones y entornos ejecutándose al mismo tiempo. Tiene aislamiento de contexto para que puedan tener pruebas para nuevas pestañas y clics que se abren en una nueva pestaña, puede capturar videos y capturas de pantalla para que puedan tener pruebas visuales en comparación. Pero es un framework nuevo, así que tengan en cuenta que hay algunos tipos de características que no están completamente desarrolladas, por lo que si buscan un framework establecido, tal vez Playwright no sea la opción. Y dado que es un framework nuevo, la comunidad no es muy grande en comparación con los otros dos, por lo que necesitarán tener algo de experiencia en programación y conocimientos, y buscar cosas porque estarán un poco solos en esto. Tendrán la comunidad de Playwrights para resolver dudas, pero Stack Overflow no está realmente lleno de preguntas y respuestas sobre cómo avanzar con Playwright. Así que tengan en cuenta que necesitarán dedicar mucho tiempo a intentar avanzar con Playwright y la documentación es un poco confusa porque, dado que hace muchas cosas, es un poco complicado trabajar con ella.

3. Choosing Frameworks, Reporting, and Planning

Short description:

Si quieres un framework que lo haga todo, elige Playwright. Elige un framework que cumpla tus necesidades. Cada framework tiene opciones para pruebas de accesibilidad. Xray y TestRail son opciones para informes, siendo Xray más integrado y visible para el equipo. Prioriza tus pruebas y documenta tu trabajo.

con. Pero si quieres tomarte el tiempo para trabajar con el framework que lo hace todo por sí mismo, creo que será muy bueno trabajar con Playwright. Así que en general, creo que debes elegir con qué te sientes cómodo. Así que echa un vistazo al árbol, juega un poco con cada uno de ellos, si tienes tiempo, y elige uno con el que te sientas cómodo trabajando. Porque esto es algo con lo que vas a trabajar, como, seis horas de tu día. Así que no elijas uno porque tu amigo te dijo que es el mejor o porque yo te digo que es el mejor. Simplemente elige uno con el que te sientas cómodo y que cumpla la mayoría de las necesidades que tienes para testing una aplicación. Así que, pasando a esto, terminarás con un tablero, o deberías terminar con un tablero, más o menos como este, donde tienes el tipo de prueba que necesitas a la derecha, en la izquierda, lo siento, y marca y cruz o arriba y abajo del framework que estás comparando. Y solo como una nota adicional, cada uno de ellos tiene opciones para trabajar con pruebas de accessibility. El que conozco es AX, que puedes integrar con los frameworks, y puedes usar ApliTools para cada uno de estos tres para ejecutar pruebas visuales. Ten en cuenta que Cypress y Playwright hacen esto por sí mismos con capturas de pantalla y videos, pero si quieres que un tercero trabaje en esto, puedes trabajar con ApliTools. Después de esto, elegirás, o no, un informe, y esto será una comparación rápida porque no quiero profundizar mucho en esto, porque creo que elegir un informe no es una decisión solo del equipo de calidad, debería ser una decisión de todo el equipo de producto porque todos deberían estar integrados en el proceso. Pero solo en una comparación rápida, Xray tiene integración con Jita, TestRail también tiene integración con Jita, pero no es tan obvio que esté allí. Y Xray, puedes crear planes de prueba, ejecución de pruebas para integrar con los problemas que tienes en Jita, teniendo en cuenta que trabajas con Jita. Si no trabajas con Jita, esta no es una muy buena opción para ti. Pero en mi opinión, Xray es una herramienta más integrada con Jita y visible para todos en el equipo lo que se está testing y lo que se está haciendo para el equipo de calidad. Y TestRail está más en el lado negativo. Así que si quieres una herramienta con la que el equipo de calidad trabajará por separado de todos los demás equipos, iría con TestRail. Y si quieres una herramienta más integrada con el proceso y el equipo de producto y el equipo de desarrollo, iría con X-Ray.

Pero pasando a la parte del plan. Eso es lo importante... No diré lo importante, pero la parte en la que debes dedicar un poco más de tiempo para entender cómo lo vas a hacer. Así que la palabra clave aquí es priorizar. Y lo que quiero decir con priorizar es elegir qué pruebas vas a hacer primero. Y esto podría ser la prueba de extremo a extremo más dolorosa que haces manualmente. Y puede ser la prueba más simple que haces solo para comenzar y tratar de entender si puedes trabajar con este framework. Así que simplemente une a un equipo y si estás solo no te sientas triste, simplemente hazlo. Y piensa en ello, siéntate realmente y mira lo que vas a hacer y cuál va a ser lo primero que vas a hacer. Y paralelamente a esto, haz documentation. Esto es muy importante porque el conocimiento no puede estar solo en tu mente, necesitas compartirlo con el mundo, con el equipo, con la empresa para que las personas sepan lo que estás testing para asegurarse de que la aplicación es estable para ir a producción. Y solo para que tengas un lugar donde puedas confiar para entender

4. Importance of Documentation and Confidence

Short description:

La documentación es esencial para recordar tus pensamientos iniciales, mostrar a otros lo que se está probando y establecer buenas prácticas. A pesar de cierta reticencia, tomar el tiempo para documentar será apreciado al final. Una vez que tengas tu lista de pruebas, el framework elegido y las priorizaciones, programa una reunión con la dirección. Presenta tu trabajo con confianza, ya que es el mejor enfoque para el equipo y el producto. Comparte tu confianza con la dirección y ellos apoyarán tus esfuerzos. Disfruta del proceso y no dudes en hacer preguntas.

Recuerda lo que hiciste en el pasado. Porque ahora mismo, si estás comenzando, es muy fácil entender lo que estás haciendo, pero en 6 meses, o 1 año a partir de ahora, realmente dudo que recuerdes lo que estabas pensando cuando comenzaste el proyecto. Entonces, si tienes documentación, te ayudará a tener un lugar al que acudir, para recordar lo que estabas pensando al principio, para mostrar a otras personas qué se está probando en la aplicación, y es una buena práctica. Sé que a algunas personas del equipo de desarrollo realmente no les gusta tomarse el tiempo para hacer documentación, pero simplemente hazlo. Es una buena práctica y me lo agradecerás al final, créeme. Y después de tener esto, después de tener la lista de tipos de pruebas que quieres elegir y que eliges hacer, lo siento, el framework que eliges usar, el autor que crees que es el mejor para que el equipo lo use y las priorizaciones de las pruebas que vas a implementar, ahora es el momento de programar una reunión con el equipo de dirección o con el gerente. Así que estructura esto de manera que cuando lo presentes, no haya opción para que digan que no. Así que hiciste todo el trabajo, analizaste el producto, buscaste los frameworks, planificaste el trabajo que vas a hacer en el próximo mes, dos meses, en el futuro. Así que preséntalo con la certeza de que el equipo y tú quieren hacer esto y están muy seguros de que esto es lo mejor para el equipo y para el producto y ten confianza al respecto. Esto es importante decirlo porque creo que a veces la gente solo piensa que esta es mi opinión, pero ten mucha confianza en que esto es lo mejor que se puede hacer y lo vas a hacer. Y comparte esa confianza con el equipo de dirección y ten la seguridad de que no te cortarán las alas, estarán realmente muy contentos de dejarte hacer esto. Así que diviértete mucho trabajando en esto, programando o no programando, y si tienes alguna duda, simplemente inténtalo. Muchas gracias y nos vemos la próxima vez. Adiós.

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

Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
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.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Top Content
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.
JSNation Live 2021JSNation Live 2021
29 min
Making JavaScript on WebAssembly Fast
Top Content
JavaScript in the browser runs many times faster than it did two decades ago. And that happened because the browser vendors spent that time working on intensive performance optimizations in their JavaScript engines.Because of this optimization work, JavaScript is now running in many places besides the browser. But there are still some environments where the JS engines can’t apply those optimizations in the right way to make things fast.We’re working to solve this, beginning a whole new wave of JavaScript optimization work. We’re improving JavaScript performance for entirely different environments, where different rules apply. And this is possible because of WebAssembly. In this talk, I'll explain how this all works and what's coming next.
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

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
React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Top Content
WorkshopFree
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
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.