Probando Aplicaciones Vue 3 con Mock Service Worker

Rate this content
Bookmark

En esta charla, discutiremos algunas mejores prácticas para probar aplicaciones Vue 3. Exploraremos cómo Mock Service Worker y Vue Testing Library pueden ayudarnos a probar aplicaciones Vue 3 de manera más cercana a una situación de usuario real. Los asistentes saldrán con una comprensión sólida de cómo probar eficazmente sus aplicaciones Vue 3 para garantizar la confiabilidad y mantenibilidad.

24 min
15 May, 2023

Video Summary and Transcription

Esta charla discute la prueba de aplicaciones V3 con Mock Service Worker, que es una biblioteca que permite simular respuestas del servidor en pruebas. Cubre la configuración de Mock Service Worker mediante la creación de respuestas de API simuladas y su conexión con la aplicación. La charla también explica cómo escribir pruebas unitarias para componentes asíncronos utilizando el componente suspense de Vue. Demuestra cómo probar componentes que interactúan con APIs y manejan respuestas de error. Además, menciona la biblioteca de pruebas para componentes sin llamadas a API y enfatiza la importancia de probar las interacciones de los componentes y la integración de la API.

Available in English

1. Testing V3 Applications with Mock Service Worker

Short description:

Hola. Hoy hablaré sobre cómo probar aplicaciones V3 con Mock Service Worker. Exploraremos cómo usar V3 con Mock Service Worker para mejorar la calidad del código y las pruebas. Probar aplicaciones V3 es crucial para detectar errores temprano y aumentar la confianza en el código. Mock Service Worker es una biblioteca que te permite simular respuestas del servidor en las pruebas, lo que es útil para aplicaciones grandes con interacciones de API. También es excelente para ejecutar pruebas unitarias en un entorno de integración continua. Veamos un ejemplo utilizando Mock Service Worker en una aplicación Vue 3 para simular respuestas de API y probar componentes que interactúan con la API.

Hoy quiero hablarte sobre cómo probar aplicaciones V3 con Mock Service Worker. Soy Lizzie. Soy una arquitecta de frontend en Storyblock. Puedes encontrarme en Twitter, pero lo más importante, puedes encontrar todos los ejemplos que hice para esta charla en este repositorio de GitHub.

Y vamos directo al grano. Esta charla se basa un poco en Harry Potter. Y descubriremos cómo podemos usar V3 junto con Mock Service Worker para mejorar nuestro código calidad y probar de una manera mejor y más integrada.

Entonces, ¿por qué es importante probar aplicaciones V3? Es realmente crucial para perfeccionar tu código, asegurarte de que esté haciendo lo que debería. Realmente puede ayudarte a detectar errores antes de que se vayan a producción, porque si detectas un error en producción, es mucho más costoso. Así que cuanto antes detectes los errores, mejor. Y realmente puede ayudar a aumentar la confianza en tu código y en el código que estás escribiendo y también en el código que estás modificando.

Entonces, ¿qué es Mock Service Worker? Mock Service Worker es una biblioteca muy útil que puedes instalar en tu aplicación y te permite simular respuestas del servidor en tus pruebas. Puedes crear una API simulada y probar cómo tu aplicación está manejando las respuestas del servidor y también manejar casos extremos de respuestas del servidor, que podrían devolver errores. ¿Por qué usarlo? Es realmente importante en aplicaciones grandes que tienen muchas interacciones con la API. Muchas aplicaciones grandes como Storyblock, tienen muchas interacciones con la API y tú quieres asegurarte de que todos estos diferentes componentes estén funcionando como deberían con estas diferentes respuestas que puedes obtener de la API. También es muy útil si ejecutas tus pruebas unitarias en un entorno de integración continua. Por ejemplo, ejecutas tus pruebas unitarias en GitHub Actions, y dentro de ese entorno de integración continua no puedes llamar a la API. Así que necesitas simular la API y ejecutar las pruebas unitarias con respuestas simuladas reales. Y ahí es donde usar Mock Service Worker es realmente útil.

Muy bien, veamos el ejemplo que construí y cómo podemos configurarlo. Para comenzar a usar Mock Service Worker, puedes usarlo en una aplicación Vue 3. Necesitas algún tipo de entorno de testing. En este ejemplo, usaremos vitest, pero funciona igual con Chest. Y necesitas Mock Service Worker, que es la biblioteca que está en el núcleo de esta charla. El ejemplo que construí muestra mis bestias mágicas. Tenemos un titular. Tenemos algunas tarjetas con el USB stick, y podemos hacer clic en esas tarjetas y ver más detalles de la bestia mágica. Y todo el contenido aquí se carga desde una API. Tengo un espacio de Storyblock donde configuré algún contenido.

2. Setting up Mock Service Worker

Short description:

Tengo una página que tiene el titular y las diferentes bestias mágicas. Obtengo el contenido real de la API de Storyblocks para mostrar los detalles de la bestia mágica. Para simular la API, creo un directorio de simulación con archivos JSON que replican las respuestas de la API. Luego, configuro el mock service worker y los controladores. Esto implica crear un archivo de configuración y conectar el mock service worker con YDist.

Tengo una página que tiene el titular y las diferentes bestias mágicas. Y luego también puedo ver lo que se devuelve realmente allí. A través de la API de Storyblocks, obtengo el contenido real que luego puedo usar para mostrar mi contenido, lo mismo para las páginas más específicas. Así que tengo una bestia mágica y luego tengo algún contenido aquí que muestra todos los detalles de esa bestia mágica.

Muy bien. Entonces, empecemos. Lo primero para configurar el mock service worker es que realmente necesitas algún tipo de API, necesitas alguna forma asincrónica de interacción. En mi ejemplo, tengo un componente que realiza una simple solicitud a la API de Storyblocks y que tiene todas las respuestas. Y luego, a partir de esa respuesta, construyo la página real que vemos. Y la parte importante aquí es que ahora necesitamos simular la API. Así que nuestro primer paso es crear un directorio de simulación. En la raíz de nuestro proyecto, podría ser en otro lugar, pero lo haré en la raíz. Y luego configuramos el mock service worker.

Entonces, ¿qué quiero decir con un directorio de simulación? Si miramos el ejemplo, tenemos una carpeta llamada mocks. Y luego tenemos dos archivos JSON. Así que tenemos el archivo beast JSON, que es la página de inicio. Y luego tenemos el archivo niffler JSON, que es una simulación de la página más específica. ¿Cómo puedes obtener esos JSON? Lo más sencillo es tener tu aplicación y luego verificar en la red qué es lo que realmente devuelve la API. Así que si recargamos eso, mi simulación aquí es básicamente esta solicitud y esta respuesta que tenemos aquí. Así que la historia, simplemente puedo copiar eso y pegarlo aquí en mi archivo beast JSON. Así que este es solo una copia de lo que tenía en esa página. Así que esa es realmente la primera parte, tener algunas simulaciones que puedan ser utilizadas por el mock service worker, pero también por otras pruebas unitarias que pueden no necesitar el mock service worker.

Luego, el siguiente paso es configurar el mock service worker y configurar algunos controladores. Para configurar el mock service worker, necesitamos crear un archivo de configuración. En la configuración de YDist, podemos configurar algunos archivos de configuración. Entonces proporcionarás la ruta al archivo que configura nuestro entorno de pruebas. Aquí en la configuración de prueba, tengo este archivo index.js que tiene mi configuración global de pruebas. Así que esa es la configuración que se utiliza en todas las pruebas que estoy escribiendo. También tengo algunas otras cosas aquí, pero la parte importante está aquí, el archivo de configuración del mock service worker, donde conecto el mock service worker con YDist. Antes de todo, después de todo y después de cada prueba, estamos iniciando el servidor, cerrando el servidor y luego restableciendo los controladores después de cada prueba.

3. Mock Service Worker para pruebas eficientes

Short description:

La parte principal de la configuración del mock service worker es importarlo y proporcionar controladores. Los controladores conectan la API con métodos específicos, como las solicitudes GET, y devuelven una respuesta simulada en formato JSON. Esta configuración nos permite escribir pruebas unitarias para páginas o puntos finales específicos. Con el servidor y los controladores en su lugar, podemos comenzar a escribir nuestra primera prueba unitaria.

Y luego el servidor real que estamos creando. Así que esa es la parte principal. Estamos importando desde el mock service worker y le estamos proporcionando algunos controladores. Los controladores son la parte principal de la configuración del mock service worker. Y lo que hacen los controladores es que conectan una API REST, o también puedes hacerlo con una API GraphQL con un método específico. Por ejemplo, dices que tienes una solicitud GET, una solicitud GET REST que causa el punto final de la API de Storyblocks, lo que sea. Y cuando eso sucede, quiero devolver el estado 200 y luego por favor devuelve un JSON de esta simulación que acabamos de crear. Así que estamos devolviendo una respuesta simulada y podemos usarla en nuestras pruebas unitarias. Hacemos lo mismo para la página más específica de esa bestia mágica. Así que aquí estamos conectando realmente la respuesta de ejemplo en formato JSON con el punto final y esta conexión nos ayudará a escribir las pruebas unitarias. No necesitas mucho más que eso, configurar el servidor y configurar los controladores y luego ya podemos empezar a volar y escribir nuestra primera prueba unitaria.

4. Escribiendo pruebas unitarias para componentes asíncronos

Short description:

Para escribir una prueba unitaria para esta página, debemos tener en cuenta sus componentes y su naturaleza asíncrona. El componente suspense de Vue nos ayuda a manejar el comportamiento asíncrono. Importamos el componente asíncrono y lo envolvemos en un componente suspense para las pruebas. Para esperar a que ocurra la solicitud fetch, creamos un espía en window fetch. Luego montamos el componente usando la función mount de las utilidades de prueba de Vue. Después de esperar a que se realice la solicitud fetch, utilizamos el ayudante flush promises para asegurarnos de que las promesas se resuelvan. Finalmente, escribimos las pruebas y accedemos al elemento h1.

El siguiente paso aquí es realmente escribir una prueba unitaria para esta página. Cuando escribimos una prueba unitaria, tenemos que pensar, ¿qué hace? Muestra un titular y tiene tres tarjetas con algún contenido. La configuración de la vista es bastante simple. Pero la complejidad aquí radica un poco en la asincronía. Estamos probando un componente asíncrono. Y en Vue, podemos hacerlo envolviéndolo en un componente suspense. Este es un componente bastante nuevo en Vue 3 que puede ayudarnos a lidiar con el comportamiento asíncrono.

Muy bien. Veamos más a fondo. Tenemos ese archivo en nuestro Vue que es asíncrono, como aquí, por ejemplo. Tenemos algo de HTML. Y la parte importante es que tenemos un fetch y debemos esperar la respuesta del fetch. Si observamos ese componente, podemos ver aquí que estamos importando el componente. Y luego lo envolvemos en un componente asíncrono solo para poder probarlo, porque es un componente asíncrono. Y luego podemos escribir la prueba real.

En la prueba real, lo que hacemos es, como es asíncrono, esperamos a que ocurra la solicitud fetch. Cómo puedes hacer eso junto con el mock service worker es creando un espía. Estamos creando un espía en window fetch, y lo llamaremos getSpy. También puedes hacerlo con Axios. Entonces podrías crear un espía que funcione con Axios y haga el mismo tipo de espionaje. Realmente depende de la forma en que estés utilizando para comunicarte con tu API y obtener tus respuestas. El siguiente paso es montar realmente el componente. Obtenemos esta función mount de las utilidades de prueba de Vue. Y luego viene la parte asíncrona. Esperamos a que esta función get, esta función fetch, haya sido llamada una vez. Y luego usamos un ayudante que se llama flush promises. Es un ayudante para las utilidades de prueba de Vue que nos ayuda a asegurarnos de que las promesas se resuelvan. Y finalmente, escribimos las pruebas. Obtenemos el envoltorio para la prueba. Obtenemos el elemento h1.

5. Prueba unitaria conectada con Mock Service Worker

Short description:

Obtenemos el texto del elemento h1 y nos aseguramos de que coincida con 'mi bestia mágica'. Verificamos que haya exactamente tres elementos con la clase VA card, simulando tres tarjetas en la prueba unitaria. La configuración global de la prueba obtiene automáticamente la respuesta JSON cuando se llama al punto final, lo que permite que el componente funcione como lo haría en un entorno real. Los casos de prueba incluyen verificar si se muestra el encabezado, si hay tres tarjetas y si la segunda tarjeta muestra el contenido esperado. MockServiceWorker puede simular respuestas de error o retrasos más largos creando nuevos controladores. Los controladores de error devuelven un estado 403 y un mensaje de error, imitando un escenario en el que un usuario llama a un punto final no autorizado.

Obtenemos el texto de eso. Y dijimos, bueno, el texto de mi elemento h1 debería ser 'mi bestia mágica'. Luego encontramos todos los elementos que tienen la clase VA card. Y decimos, bueno, debería haber tres elementos que tengan la clase VA card. Así que son tres tarjetas. Nos aseguramos de que haya exactamente tres tarjetas en esta prueba unitaria. Y eso es básicamente nuestra prueba unitaria conectada con Mock Service Worker. Y es bastante genial porque no tenemos que escribir estas simulaciones extensas y complicadas. Pero con esta configuración global de prueba, cuando se llama a nuestro punto final aquí con el window fetch, automáticamente obtendrá este JSON que tenemos aquí. Y el componente funciona como funcionaría también en el entorno real. Y luego, cuando escribimos la prueba, podemos asegurarnos de que la configuración de ese componente sea realmente como debería ser.

Veamos la prueba que escribimos aquí. Un segundo, acabo de ejecutar el archivo. Aquí, tenemos este beforeEach. Monta el componente antes de cada prueba para no tener que volver a escribir esto en cada prueba. Luego tenemos los diferentes casos de prueba. El primero dice que se debe mostrar el encabezado. Deben haber tres tarjetas. Luego también tenemos otro caso de prueba en el que decimos que la segunda tarjeta siempre debe mostrar un elemento if-not que prueba realmente ese contenido que tenemos allí para asegurarnos de que se muestre el contenido de la manera que queremos mostrarlo. Muy bien, eso ya está conectado.

Y ahora viene la parte interesante porque MockServiceWorker no solo puede simular estas respuestas positivas, sino que también puede simular respuestas de error o retrasos más largos. Y podemos hacer eso simplemente creando nuevos controladores que devuelvan algo diferente. Entonces, dentro de nuestras simulaciones, creé un archivo llamado controladores de error. Y los controladores de error se ven muy similares a los controladores que teníamos antes. Nuevamente, utiliza el método rest de MockServiceWorker. Hacemos una solicitud GET al mismo punto final, pero en lugar de devolver un estado de contexto 200, ahora devolvemos un estado de contexto 403. Y luego el punto final devolverá un mensaje de error con 'no permitido'. Eso básicamente simularía un comportamiento en el que dirías que un usuario está llamando a un punto final al que no se le permite llamar a esa entrada. Por ejemplo, un usuario está llamando a un punto final de administrador, pero es posible que el usuario no sea un administrador. Para mostrarte a qué me refiero en el navegador, puedo mostrártelo aquí.

6. Prueba de respuestas de error y casos límite

Short description:

Entonces aquí, podemos bloquear una URL y ver el error. Adapté mi componente para manejar respuestas de error. Para probar este comportamiento, importa el servidor y los manejadores de error, crea un conjunto de pruebas para solicitudes fallidas y verifica si el HTML contiene la respuesta de error. Las pruebas con respuestas de API fallidas garantizan la cobertura de posibles fallas. Mock Service Worker facilita y potencia las pruebas, permitiendo probar casos límite como API retrasadas o mensajes de error personalizados. Los MOCs se pueden usar en pruebas unitarias sin el MOC del service worker.

Entonces aquí, si volvemos a mirar la red, recarguemos eso. Y luego podemos bloquear esto. Podemos bloquear esta URL. Y ahora, si recargamos, no puede cargarse porque esta URL está bloqueada. El navegador no nos permite hacerlo. Y luego vemos este error aquí.

Entonces adapté mi componente para poder manejar este tipo de respuesta de error. Así que dentro de mi vista principal, se ha vuelto un poco más complicado donde verifiqué la respuesta. Verifiqué el estado de la respuesta. Y si no es 200, lanzo un error. Y este error se muestra en mi página. Y ahora puedo escribir la prueba para ello.

Entonces, para probar este comportamiento con errores, lo que necesitamos hacer es importar nuestro servidor que estamos usando y que está activo. Y necesitamos importar nuestros manejadores de error que tienen las respuestas de manejo de errores reales. Y luego puedo escribir un nuevo conjunto de pruebas para las solicitudes fallidas. Y puedo decir, por favor, usa el servidor con los manejadores de error en lugar de los otros manejadores regulares para ver cómo se comporta mi componente con una respuesta de API fallida. Luego espero a que se cargue y termine. Y luego escribo el caso de prueba donde digo que mi HTML debe contener esta respuesta de error que se devuelve desde el manejador de errores. El texto que devuelve la API debe mostrarse en mi HTML. Y si miramos estos manejadores de errores, este es el mensaje que se devuelve aquí. Y luego estás probando el mismo componente, el mismo componente asíncrono, con respuestas de API fallidas reales, lo que lo hace aún más claro y asegura que también estamos cubriendo casos donde la API puede fallar. Así que esto es realmente genial. Y esto es algo que es bastante difícil de hacer cuando tienes que escribirlo tú mismo y no tienes el mock service worker. Así que tienes que hacer mucho más sin el mock service worker para obtener este tipo de comportamiento de prueba. Así que es realmente, realmente poderoso. También puedes probar otros casos límite. Las API tienen un comportamiento inusual y puedes probar casos de prueba, por ejemplo, donde la API se retrasa dos segundos. O puedes probar casos donde tienes algún mensaje de error personalizado o alguna respuesta personalizada porque ocurrió algún caso personalizado, como un usuario llamando a un punto final que no debería llamar. Por supuesto, el mock service worker no es la única forma de probar. También puedes usar estos MOCs que creamos en pruebas unitarias que no utilizan el mock service worker.

7. Pruebas de componentes sin llamadas a la API

Short description:

Para los componentes que no llaman a una API, se recomienda utilizar la biblioteca de pruebas. Es un envoltorio alrededor de las utilidades de prueba de vista, que proporciona una mejor prueba de accesibilidad. Asegura que los elementos correctos estén en la pantalla y prueba la interacción del usuario. Veamos un ejemplo de prueba de un componente con un comportamiento de clic. El componente es un componente de vista simple que recibe una propiedad llamada Bloque. La prueba importa las funciones y componentes necesarios, configura los datos simulados, renderiza el componente y ejecuta los casos de prueba.

Entonces, para los componentes que tal vez no llamen a una API, solo sean componentes regulares que no sean asíncronos. Para las unidades más pequeñas, realmente puedo recomendar el uso de la biblioteca de pruebas. Es un envoltorio muy bueno alrededor de las utilidades de prueba de vista que pueden probar incluso mejor para la accesibilidad. Puede probar si los elementos correctos están en la pantalla. Puede probar la interacción del usuario. Así que es realmente bueno para probar estos comportamientos de clic o comportamientos de campo de entrada para asegurarse de que sus componentes se comporten como deberían para la interacción del usuario.

Y les mostraré un caso rápido de nuestro ejemplo. Así que desactivemos el bloqueo aquí. Si vamos a nuestro elemento aquí, es un componente simple que recibe una propiedad. Y ahora queremos probar ese componente y tal vez probar este comportamiento de clic que tenemos aquí en los botones, o que tenemos un botón. Les mostraré la prueba real.

Entonces, este es nuestro componente. Es un componente de vista simple con mucho HTML. Y básicamente solo recibe una propiedad llamada Bloque. Eso es muy común en aplicaciones que usan Storyblock. Y luego todo lo que se muestra aquí se basa en esta propiedad de bloque que está recibiendo. Y luego aquí podemos ir a la prueba para este componente. Y aquí vemos que estamos importando las funciones de renderización de pantalla y eventos de la biblioteca de pruebas de vista. Entonces, esas son las funciones principales que necesitarías al probar con esta biblioteca. También estoy importando la configuración porque quería que recibiera parte de la configuración global que ya había configurado. Y luego importo el componente.

Aquí no necesito este envoltorio asíncrono porque no es un componente asíncrono que está esperando alguna respuesta de API. Es solo un componente simple. También estoy importando esta simulación que creé al principio donde simplemente copié la respuesta que obtuve del servidor. Luego creo la propiedad real que se pasa al componente. Entonces, lo que se pasa al componente está dentro de toda esa simulación. Así que obtengo la parte específica de la simulación que necesito pasar al componente. Luego renderizo el componente real. Paso el contenido, la simulación, a ese componente. Y luego puedo tener diferentes casos de prueba.

8. Pruebas de interacciones de componentes e integración de API

Short description:

Además de probar atributos específicos, esta biblioteca permite probar interacciones y garantizar el comportamiento del componente. Al utilizar las mismas simulaciones que el mock service worker, podemos definir el punto de interacción entre la API y la aplicación en un solo lugar. Esto asegura que los componentes estén trabajando con los datos de la API y ayuda a prevenir fallos en la aplicación. Para obtener más recursos, consulta la documentación de mockserviceworker, la biblioteca de pruebas para probar componentes e interacciones, y las guías de Vue.js sobre comportamiento asíncrono y suspense. También puedes usar Storyblock para crear tus propias APIs. ¡Pruébalo en tu aplicación Vue 3!

Aquí estoy probando que el nombre de la pieza mágica, la descripción y la imagen estén presentes. También puedo hacer pruebas. Y lo bueno de esta biblioteca es que puedo probar mediante el texto alternativo. Puedo probar mediante marcadores de posición. Y esto puede ser realmente útil para hacer que tu aplicación sea más accesible, ya que no solo realizamos pruebas para pruebas específicas, sino para atributos HTML reales.

Y finalmente, también puedo probar algunas interacciones. Aquí estoy diciendo que quiero tener exactamente un botón con el texto. Y luego, cuando hago clic en ese botón, quiero asegurarme de que este componente emita el evento específico. Esto básicamente prueba este comportamiento de que este componente emite un evento cuando hacemos clic en él. Y ahora, si alguien fuera a este componente y eliminara este botón, nuestra prueba unitaria fallaría. Veríamos que algo salió mal porque ya no cumple con este comportamiento de botón. Lo mismo sucedería si esta persona cambiara este botón por un div. La prueba unitaria fallaría porque hemos sido muy específicos al decir que debería haber un botón con ese nombre que debería emitir exactamente este evento. Y esto nos ayuda a asegurarnos de que nuestra aplicación no se rompa.

Y como puedes ver aquí, no está utilizando un mock service worker. No es asíncrono, pero está utilizando las mismas simulaciones que también usamos junto con el mock service worker. Y eso es realmente útil porque tenemos un lugar donde definimos el punto de interacción entre la API y la aplicación. Entonces, si todas las pruebas están utilizando el mismo tipo de simulaciones y si mi API está cambiando, también tengo que cambiar las simulaciones. Pero puedo asegurarme de que mis componentes y mis componentes cuando los estoy probando realmente estén funcionando con todas las cosas que provienen de mi API.

De acuerdo, eso es básicamente todo. Tengo algunos recursos más. Mockserviceworker tiene una documentación realmente buena. La biblioteca de pruebas es realmente excelente para probar componentes simples y probar interacciones. Vue.js también tiene muchas guías excelentes sobre cómo trabajar con comportamiento asíncrono, cómo trabajar con suspense y también cómo probar el comportamiento asíncrono porque en realidad no es tan fácil. Y sí, también puedes usar Storyblock para crear tus propias APIs. Y sí, fue realmente divertido hacerlo y aprenderlo y configurarlo. Espero que uses este repositorio para probarlo en tu propia aplicación Vue 3. Muchas gracias por escuchar. ♪♪♪

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

Vue.js London Live 2021Vue.js London Live 2021
20 min
One Year Into Vue 3
Top Content
Vue 3 may still sound new to many users, but it's actually been released for over a year already. How did Vue 3 evolve during this period? Why did it take so long for the ecosystem to catch up? What did we learn from this process? What's coming next? We will discuss these questions in this talk!
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.
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
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
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.