Explorando Módulos Node para Automatización de Pruebas

Rate this content
Bookmark

En mi charla exploraré los desafíos que se enfrentan al intentar gestionar y mantener el código de prueba en múltiples proyectos y qué me hizo crear mi primer módulo Javascript. Mostraré el proceso de construcción, publicación y versionado utilizando las poderosas capacidades de GitHub Actions. Y finalmente, hablaré sobre los beneficios de hacerlo.

19 min
11 Dec, 2023

AI Generated Video Summary

Esta charla explora el proceso de construcción de una biblioteca de automatización de pruebas utilizando módulos node, con un enfoque en la creación de la estructura del proyecto, la construcción y prueba de la biblioteca, y la publicación y versionado del paquete. Se discute la inclusión de características útiles como los ayudantes WAIT y el uso de bibliotecas como Playwright y Cypress. Se enfatiza la importancia de una documentación clara, versiones previas a la publicación y control de versiones, junto con la necesidad de instrucciones de instalación y pautas de contribución.

1. Introducción a la Construcción de la Biblioteca de Automatización de Pruebas

Short description:

Hablaré sobre la exploración de módulos de nodo para la automatización de pruebas. Te guiaré a través del proceso de construir tu propia biblioteca, publicarla en npm y luego usarla. Hoy, hablaré sobre la creación de un proyecto de módulo con PMPM y VIT. Hablaré sobre el desarrollo guiado por pruebas, probándolo. Hablaré sobre la selección de registros NPM, es decir, dónde publicarás tu paquete. Te mostraré un ejemplo del flujo de trabajo de la tubería de GitHub utilizado para publicar una nueva versión, pero también prelanzamientos. Hablaré sobre lo importante que es la versión del proyecto y la importancia de agregar un Readme. Pero antes de comenzar a sumergirnos en cómo construir tu propia biblioteca, me gustaría hacer la pregunta, y tal vez discutir primero, ¿qué incluiría esta biblioteca? ¿Qué tipo de ayudantes? A menudo te encuentras copiando y pegando de proyecto a proyecto, así que ¿qué ayudantes serían buenos para estar en esta biblioteca de pruebas? A menudo me encuentro usando ayudantes WAIT. No importa si trabajas con Playwright, Cypress, Selenium.

Hola a todos, mi nombre es Kat Kniotek. Trabajo como ingeniera de calidad en Houseful, anteriormente conocida como Zoopla. Gracias por unirte a mi charla hoy.

Hablaré sobre la exploración de los modules de nodo para la automation de pruebas. Te guiaré a través del proceso de construir tu propia biblioteca, publicarla en npm, y luego usarla.

Entonces, podríamos comenzar con la pregunta, ¿por qué? ¿Por qué crearías tu propia biblioteca para la automation de pruebas? Así que, estaba trabajando con dos enfoques para las pruebas. El primero, el marco de pruebas viviría en un repositorio separado. Sería un lugar único para administrar las dependencias de las pruebas. Las pruebas compartirían ayudantes y métodos de configuración. Las pruebas serían mantenidas por el equipo de QA. Podrías tener frameworks separados para las pruebas de UI y para las pruebas de API, pero principalmente el equipo de QA sería responsable de actualizarlo, agregarlo, depurar pruebas inestables. El segundo enfoque con el que trabajé, y siendo honesta, es que las pruebas viven con el proyecto, con el proyecto de la aplicación. Y luego pueden ser mantenidas por los desarrolladores. Entonces, digamos que configuraría este marco y los desarrolladores estarían agregando pruebas, actualizando pruebas según sea necesario. Sin embargo, este enfoque introdujo mucha duplicación de código. Cada vez que estamos creando una nueva API, un nuevo servicio, me encontraba copiando, pegando de un proyecto a otro ayudantes, la configuración de configuración para el proyecto. Y también cuando tenía que actualizar una de las dependencias, dependencias de prueba, tenía que actualizar en cinco lugares. Realmente no era el camino a seguir. Por eso decidí investigar la construcción de mi propia biblioteca que incluiría todos los ayudantes que copio y pego de repositorio a repositorio. Podría simplemente instalar esta biblioteca en un proyecto y luego usar ayudantes según sea necesario.

Entonces hoy, hablaré sobre la creación de un proyecto de módulo con PMPM y VIT. Hablaré sobre el desarrollo guiado por pruebas, testing. Como ingenieros de automation, no a menudo tenemos la oportunidad de practicar TDD. Esta es la oportunidad. Hablaré sobre la selección de registros NPM, es decir, dónde publicarás tu paquete. Te mostraré un ejemplo del flujo de trabajo de la tubería de GitHub utilizado para publicar una nueva versión, pero también prelanzamientos. Hablaré sobre lo importante que es la versión del proyecto y la importancia de agregar un Readme. Esos son algunos puntos que trataré. Pero antes de comenzar a sumergirnos en cómo construir tu propia biblioteca, me gustaría hacer la pregunta, y tal vez discutir primero, ¿qué incluiría esta biblioteca? ¿Qué tipo de ayudantes? A menudo te encuentras copiando y pegando de proyecto a proyecto, así que ¿qué ayudantes serían buenos para estar en esta biblioteca de pruebas? A menudo me encuentro usando ayudantes WAIT. No importa si trabajas con Playwright, Cypress, Selenium.

2. Creación de la Biblioteca de Pruebas y Estructura del Proyecto

Short description:

Podemos almacenar nuestros ayudantes WAIT personalizados, comparadores, afirmaciones y configuración en la biblioteca de pruebas. Los métodos de autenticación, los modelos de objetos de página y los ayudantes del cliente API también pueden incluirse. Para crear la biblioteca, podemos usar la herramienta de línea de comandos para pnpm y responder algunas preguntas sobre el marco, seleccionando el tiempo de ejecución como biblioteca y el lenguaje como TypeScript para la seguridad de tipo.

Todos tenemos nuestros ayudantes WAIT personalizados que probablemente sean particulares para la aplicación en la que trabajamos, y pueden almacenarse en nuestra nueva biblioteca de pruebas. Tal vez creaste tus propios comparadores y afirmaciones personalizadas, y realmente te gusta la forma en que funcionan, y quieres usarlos en otros proyectos. Así que, en lugar de copiar y pegar, puedes colocarlos en esta biblioteca de pruebas.

La configuración de tu prueba, también puede ser compartida. Los métodos de Authentication, así que digamos que trabajas con, pruebas de API, y la authentication para el servicio es CognitoToken, y cada una de las APIs, cada uno de los proyectos usa el mismo método de authentication. Así que tienes este ayudante para calcular el token base64 a partir de las credenciales. Esto también puede ir a la biblioteca de ayudantes. Modelos de objetos de página, tal vez cada una de tus pruebas interactúa con la página de inicio de sesión, y la página de inicio de sesión es la misma para todas las aplicaciones. Tal vez este modelo de objeto de página de inicio de sesión podría vivir en la biblioteca. Y los ayudantes del cliente API y la configuración, configurando encabezados personalizados y así sucesivamente.

Así que cuando estamos empezando la línea de comandos, en lugar de hacer toda la configuración del proyecto y demás, podemos usar la herramienta de línea de comandos para pnpm y crear el proyecto bit. Se te pedirá que respondas algunas preguntas sobre el marco. No estamos usando ninguna vista React o algo así. Simplemente estamos usando otro. El Runtime a seleccionar será biblioteca. Eso es realmente útil porque eso es lo que estamos construyendo. El lenguaje, seleccioné TypeScript para hacer nuestra biblioteca segura en términos de tipos. Si alguna vez has usado ese tipo de herramienta de línea de comandos, como NPX, crear aplicación React o similar, sabes que eso es lo que construirá para ti como la estructura del proyecto con mucho código predefinido.

3. Construcción y Pruebas de la Biblioteca

Short description:

En nuestro ejemplo, podemos eliminar todo lo que esté relacionado con HTML. No vamos a ejecutar nuestra aplicación en el navegador. Por lo tanto, HTML, CSS, SVG, no serán útiles en nuestro proyecto. Puedes empezar a instalar tus bibliotecas favoritas como Playwright, Cypress, FakerJS. Todos tus ayudantes deben ir al directorio lib en el archivo TS principal. Una vez que tengas definidos todos tus ayudantes, puedes exportarlos en un archivo index.d.ts.

Código. En nuestro ejemplo, podemos eliminar todo lo que esté relacionado con HTML. No vamos a ejecutar nuestra aplicación en el navegador. Así que HTML, CSS, SVG, no serán útiles en nuestro proyecto. Luego puedes empezar a instalar tus bibliotecas favoritas. Digamos Playwright, digamos Cypress, FakerJS o similares. Y todos tus ayudantes deben ir al directorio lib, al archivo TS principal. Y aquí hay un ejemplo de cómo se ve mi archivo TS principal. Tiene algunos métodos, algunas funciones. La primera es la que mencioné, me gusta usar un ayudante de espera personalizado. Esto es para Playwright. Espero una respuesta particular en la pestaña de red, y luego continúo con mis pruebas. La que también mencioné, calculando el token de Cognito a partir de las variables de entorno y devolviendo la cadena, y el ayudante de demostración para simplemente imprimir hola, nombre. Así que algo bastante fácil, fácil de probar. Y luego, una vez que tengas definidos todos tus ayudantes, bueno, puedes empezar con uno o unos pocos. Necesitas exportarlos en un archivo index.d.ts Este archivo está por defecto en la raíz de tu proyecto. Así que aquí exportas esas funciones que estarán disponibles desde la biblioteca.

Bueno, ¿y luego qué? Testing. Puedes instalar vtest. Digamos que puedes añadir tus pruebas unitarias para tus métodos, y por supuesto asegúrate de que la etapa de prueba está incluida en el pipeline en el flujo de trabajo. Pero, ¿cómo probamos realmente nuestra solución? Así que, construimos el proyecto, y, en teoría, todo está bien porque simplemente copiamos el código, trabajamos en otro lugar, ¿cómo lo probamos?, podemos instalarlo y acceder a esos métodos que son públicamente accesibles una vez que el paquete está construido. Así que, construiremos el proyecto, y luego lo empaquetaremos. Algo que sucederá en el pipeline, en el pipeline construiremos, y luego publicaremos. Publicar por defecto empaqueta nuestro proyecto. Y como resultado del comando PMPM pack, se creará un archivo, que es básicamente el nombre del proyecto de package.json con el número de versión. Y esta es nuestra biblioteca. ¿Cómo podemos probarla? Podemos crear un proyecto separado y simplemente instalarlo. Algo que aprendí como parte del trabajo en este proyecto es que puedes instalar la biblioteca desde el archivo. Así que si ejecutas pmpm install path to your file, como puedes ver en el ejemplo, eso se instalará en tu package.json. Es fantástico.

4. Pruebas y Publicación del Paquete

Short description:

Puedes probar tu paquete importándolo y actualizando los métodos si es necesario. Para hacer que tu paquete esté disponible, puedes almacenarlo en npm o usar el feed de GitHub. El flujo de trabajo de GitHub se puede utilizar para publicar el paquete, incluyendo versiones pre-lanzamiento. El flujo de trabajo se activa en las solicitudes de extracción y autentica tu inicio de sesión en el registro de npm.

Y luego puedes simplemente probarlo como importar print hello desde mis ayudantes de prueba, y funciona. Bueno, no funcionó la primera vez. Así que no te desanimes si no funciona la primera vez. Puedes simplemente actualizar los métodos. Quizás olvidaste exportarlo en el archivo index, reconstruirlo y publicarlo de nuevo, empaquetarlo de nuevo. Obviamente es un ensayo y error y es un gran aprendizaje.

Así que una vez que tenemos nuestro proyecto construido, sabemos que funciona porque podemos instalarlo en otro proyecto. Necesitamos empezar a pensar cómo lo haremos disponible en repositorios y en otros equipos. Una de las soluciones para publicar nuestro paquete sería almacenarlo en npm. Puedes registrarte en npm y publicar tu paquete allí. Si estás utilizando una cuenta gratuita, tienes permiso para publicar paquetes públicos. Sin embargo, si sientes que tu proyecto, tu módulo contiene algo relacionado con la aplicación, no quieres exponer esto al mundo exterior o algo así, simplemente no quieres hacerlo público, necesitarías una cuenta de pago o enterprise. Como no lo tengo, decidí publicar mi paquete con el feed de GitHub. También es un registro de npm. Simplemente especificas una URL de registro diferente que apunta a tu registro de GitHub. También puedes crear el paquete a nivel de organización. Puedes hacerlo privado, público. Aquí solo hay un ejemplo. Estaba usando mi propia cuenta de GitHub.

Así que podríamos usar todos los comandos como build, pack, publish localmente. Podríamos iniciar sesión en el registro localmente y publicarlo desde allí. Sin embargo, desde el punto de vista del mantenimiento, queríamos que estuviera controlado por el control de fuente, por el control de versión. Así que aquí está el ejemplo de un flujo de trabajo de GitHub que estará publicando nuestro paquete. Estará publicando el paquete pre-lanzamiento. Hablaré de ello más tarde. Pero lo que puedes ver aquí es un disparador. Así que este flujo de trabajo se activará cada vez que se cree una solicitud de extracción contra la rama principal. Esto comprobará nuestro código y creará un archivo .npmrc. Este archivo se utiliza para autenticar tu inicio de sesión en el registro de npm. Porque como puedes ver en la segunda línea, 19, incluye el secreto.

5. Publicación y Versionado del Paquete

Short description:

No quería comprometerlo con el repositorio. Por eso escribo en el archivo como un paso de la tubería y tengo acceso a mi secreto aquí. Cuando ejecutas la tubería, la salida se ve más o menos así. Está en la línea 12, tienes tu archivo index.d.ts, así que el archivo que exporta realmente métodos y funciones que se utilizan. Pero también en la línea 17, tienes exactamente el nombre del archivo que estábamos probando localmente cuando estábamos ejecutando el método pnpm pack. Si obtienes 405, asegúrate de que tu paquete esté nombrado correctamente. Una vez que lo publicas, tu paquete está disponible en GitHub. Tienes información sobre cómo instalarlo, cómo añadirlo a packet.json, tienes información sobre las versiones anteriores. En el lado derecho, también tienes el readme, y el enlace al repositorio. Hablemos ahora del versionado. El estándar para el versionado es el formato mayor, menor, parche. Eso se traduce en, digamos, mayor uno, menor tres y parche es cero. Así que, cuando vayas a lanzar un cambio importante, querrás comunicar al usuario que puede que necesite actualizar el uso de tu biblioteca, y lo haces lanzando versiones mayores. Y esto es comúnmente conocido como el problema del huevo y la gallina.

No quería comprometerlo con el repositorio. Por eso escribo en el archivo como un paso de la tubería y tengo acceso a mi secreto aquí. Ahí están los secretos del repositorio. Así que creo este archivo npmrc. Instalo las dependencias, ejecuto mis pruebas y construyo el proyecto, y luego puedo publicar, como dije, en mi registro de GitHub que incluye también mi nombre de usuario.

Cuando ejecutas la tubería, la salida se ve más o menos así. Está en la línea 12, tienes tu archivo index.d.ts, así que el archivo que realmente exporta métodos y funciones que se utilizan. Pero también en la línea 17, tienes exactamente el nombre del archivo que estábamos probando localmente cuando estábamos ejecutando el método pnpm pack. De nuevo, igual que antes, no funcionó la primera vez. No funcionó la segunda vez. Cuando intentaba publicar en mi feed de GitHub, a menudo, obtenía 404 o 405. Y descubrí la forma de autenticarlo, así que como decía, el archivo .npmrc necesita incluir el secreto y la URL correcta del registro. Sin embargo, el nombre de tu paquete también necesita incluir tu nombre de usuario de GitHub. Eso fue un aprendizaje interesante. Si obtienes 405, asegúrate de que tu paquete esté nombrado correctamente.

OK. Así que, una vez que lo publicas, tu paquete está disponible en GitHub. Tienes información sobre cómo instalarlo, cómo añadirlo a packet.json, tienes información sobre las versiones anteriores. En el lado derecho, también tienes el readme, y el enlace al repositorio. Es realmente agradable, ¿no es así? Así que, como puedes ver aquí, hay diferentes versiones, la versión reciente, hay alfa y así sucesivamente. Hablemos ahora del versionado. Así que, el estándar para el versionado es el formato mayor, menor, parche. Eso se traduce en, digamos, mayor uno, menor tres y parche es cero. Así que, cuando vayas a lanzar un cambio importante, querrás comunicar al usuario que puede que necesite actualizar el uso de tu biblioteca, y lo haces lanzando versiones mayores. Así que, digamos que aumentas el número mayor a dos, tendrás la versión 2.0.0. Si lanzas este pequeño cambio en tu aplicación, quizás solo añades una función de ayuda adicional, simplemente aumentarías la versión menor. Así que, 1.4.0. Y cuando trabajas con parches, así, como las pequeñas correcciones, quizás actualizaste el readme o algo así, simplemente actualizarías la versión del parche. Sin embargo, cuando trabajas con el paquete, y creas el PR, actualizas el código, y lanzas este paquete, probablemente crearías solo una actualización de parche 1.3.1.

6. Publicación de Pre-lanzamientos y Control de Versiones

Short description:

Al trabajar con pull releases, es común agregar versiones de pre-lanzamiento como alpha, beta o RC para evitar la publicación de cambios que rompen. A pesar de esto, sigue siendo importante publicar pre-lanzamientos para fines de prueba. Hay varias herramientas disponibles para ayudar a controlar el versionado, como package.json, Git version, GitHub actions y tags. Se recomienda elegir uno y consultar la documentación para obtener orientación. Además, es crucial proporcionar instrucciones de instalación claras, pautas de contribución y ejemplos para los usuarios, que pueden ser ingenieros de calidad o desarrolladores.

Y esto se conoce comúnmente como el problema del huevo y la gallina. Porque tu PR podría ser, tu pull request podría estar creando el cambio que rompe para el usuario, o tu código de pull request podría no estar completo, podría no estar funcionando como el usuario esperaría. Pero si tienen en su package.json, versión anclada de esta manera, en lugar de que mis ayudantes de prueba estén anclados a la versión 1.3.1, permiten que se instalen todas las versiones por encima de esta versión. Entonces, si estás introduciendo el cambio que rompe, consumirían este código como parte de la instalación de dependencias. Por eso, cuando trabajamos con pull releases, a menudo usamos, agregaremos, digamos, guión alpha, guión beta, o RC release candidate, para asegurarnos de que no estamos publicando un lanzamiento real, como el lanzamiento completo. Y lo marcamos con cualquier conversión que se use en el proyecto.

Entonces, puedes preguntar, vale, ¿por qué incluso lo publicamos si eso podría ser un cambio que rompe? Tal vez no deberíamos publicarlo aún si todavía trabajamos en pull request, si no se ha fusionado. Pero al mismo tiempo, quieres poder probarlo. Quieres publicar este pre-lanzamiento alpha, y luego quieres instalarlo en otro proyecto. Y puedes usarlo simplemente agregando alpha punto cero y npm install.

Otro aprendizaje como parte de este proyecto fue descubrir que hay muchas herramientas que pueden ayudarte a controlar el versionado de tu proyecto. Esto se puede hacer a través de package.json. Hay un atributo de versión. Esto se puede hacer con Git version, en realidad una herramienta. Esto se puede hacer con GitHub actions o tal vez con las tags de GitHub. Hay muchas formas de hacerlo. Lo que recomendaría es elegir uno de ellos y entrar en la documentation y averiguar cómo usarlo. Me confundí un poco en el camino cuando estaba trabajando en ello. Así que sí, revisa la documentation de la herramienta que decidas usar. Y léeme. Entonces, ¿quién es tu usuario? Tu usuario es otro ingeniero de calidad y tu usuario es un desarrollador. Necesitan saber cómo instalar tu proyecto, cómo contribuir a él y cómo usarlo. Así que ambos ayudantes están disponibles para ellos. Así que un ejemplo, cómo el proceso de instalación y la guía de contribución. Y eso es todo. Espero que hayas disfrutado de esta masterclass, que hayas aprendido algo nuevo. Tal vez decidas llevar este aprendizaje y construir algo para tu equipo también. Y espero que disfrutes de otras masterclass en Test.js. Gracias.

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
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
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.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
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
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
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
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.
Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
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.