De Vuex a Pinia. Cómo migrar una aplicación existente

Rate this content
Bookmark

¿Estás perdiendo la cabeza intentando convertir tu tienda Vuex a Pinia? Aquí tienes una guía paso a paso sobre cómo migrar las definiciones de tienda y las pruebas, de manera fácil y sin sufrimiento.

Denny Biasiolli
Denny Biasiolli
24 min
15 May, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Pinia es la biblioteca oficialmente reconocida para la gestión de estados en Vue.js, con una API más sencilla que Vuex y soporte para TypeScript. Migrar a Pinia implica crear una tienda raíz, definir tiendas y usar store2refs o el uso exportado de la tienda en los componentes. Probar el comportamiento real de la tienda requiere crear una instancia de Pinia, mientras que las pruebas de componentes implican importar useStore y usar mapState y mapAction de vigname. La migración de pruebas implica crear una vista local y usar el plugin de Pinia, y Vuex y Pinia pueden coexistir pero deben ser migrados módulo por módulo. La persistencia de la tienda se puede lograr suscribiéndose a los cambios de la tienda o utilizando un observador.

Available in English

1. Introducción a Pinia

Short description:

Pinia es la biblioteca oficialmente reconocida para la gestión de estado en Vue.js. Tiene una API más sencilla que VueX, no necesita mutaciones y soporta TypeScript sin envoltorios complejos. Pina puede coexistir con Vuex.

Hola, ¿estás listo para migrar tus proyectos de UX a Pinia? Bueno, empecemos juntos.

Hola, soy Danny, soy de Italia. Soy un desarrollador full stack que trabaja con Python y JavaScript, y por supuesto, Vue.js. Y trabajo para Fingerprint como desarrollador front-end.

Entonces, comencemos hablando de Pinia. ¿Qué es Pinia? Bueno, Pinia es la biblioteca oficialmente reconocida para la gestión de estado en Vue.js. Pinia comenzó como un experimento para rediseñar cómo podría ser una tienda para Vue.js con API de composición. Y por supuesto, intentaron implementar ideas y muchas cosas del equipo central de discusión para VueX5. Y luego vieron que ya estaba allí. Entonces, ¿por qué aplicar de nuevo, los mismos cambios a Vuex para crear VueX5, cuando PNIA ya estaba allí. Así que vamos a darle a PNIA y hacerlo la recomendación predeterminada ahora.

Entonces, antes de comenzar a migrar todo, hagamos una rápida comparación entre VueX y PNIA. Por supuesto, PNIA funciona con Vue.js 2 y 3 con la misma versión instalada. Así que no necesitas instalar, por ejemplo, VueX 3 para Vue.js 2 y VueX 4 para Vue.js 3. Solo necesitas instalar la última PNIA disponible. Y por supuesto que funciona. Y aparte de esto, tiene una API más sencilla que VueX porque las mutaciones ya no existen. A menudo se percibían como extremadamente verbosas. Y de nuevo, con cadenas mágicas para inyectar y así sucesivamente, eran un poco difíciles de usar. Así que no necesitas mutaciones ahora, solo acciones, pero lo veremos en un momento. Y luego no necesitas crear envoltorios complejos personalizados para soportar TypeScript porque, por supuesto, está, de nuevo, siempre implementado como una función o como un objeto. Así que es perfecto con la auto-completación y así sucesivamente. Así que no más cadenas mágicas para inyectar, importar funciones, importar métodos y propiedades, llamarlos y disfrutar de la completación. Y no necesitas añadir tiendas de forma dinámica porque todas son dinámicas por defecto. Es genial. Por la misma razón, no necesitas anidar módulos y no necesitas crear una estructura anidada para tu tienda porque son como con espacios de nombres, puedes decir. Y puedes usar una tienda dentro de otra y funciona. Simplemente genial.

Entonces, comencemos instalando Pina. Pina puede coexistir con Vuex, así que puedes instalarlos juntos.

2. Migrando a Pinia y Estructura de la Tienda Vuex

Short description:

Si estás utilizando Vue.js 3 o 2.7, puedes simplemente instalar Pina. Si estás utilizando Vue.js 2.6, necesitas instalar también Vue composition API. Para crear la tienda raíz, importa create Pina y úsalo en tu aplicación. Para una tienda raíz avanzada, crea un archivo index.js en el directorio de tiendas. Define al menos una tienda utilizando la sintaxis proporcionada. Recuerda devolver propiedades, getters y acciones en la parte inferior de la función. Para usar la tienda en componentes, importa store2refs o la tienda de uso exportada. Para Vue.js 2, importa mapState y mapActions. Ahora, preparemos la migración examinando la estructura de la tienda Vuex.

Si estás utilizando Vue.js 3 o 2.7, puedes simplemente instalar Pina. Eso es todo, pero si estás utilizando Vue.js 2.6, necesitas instalar también Vue composition API porque Pina funciona con composition API. Entonces puedes encontrar una tienda raíz de una manera básica. Así que simplemente importando create Pina y usándolo en tu aplicación. O si estás utilizando Vue.js 2.x, necesitas importar también el plugin Pina Vue y usar el plugin antes de crear Pina. Pero si quieres crear la tienda raíz de una manera avanzada, necesitas crear un archivo index.js en el directorio de tiendas, importando create Pina y creando la tienda. Algo similar para Vue.js 2.x. Y luego en tu archivo main.js, puedes importar tu Pina desde tiendas y usarlo en tu aplicación. Así que, todo lo relacionado con Pina permanecerá en la carpeta de tiendas.

Luego, después de definir la tienda raíz, llamémosla la instancia Pina, necesitas definir al menos una tienda si quieres usar una tienda. Así que, esta es la sintaxis para Vue.js 3.x y 2.x también. Así que, necesitas definir la tienda pasando el nombre de la tienda como primer parámetro, y necesita ser único entre las tiendas. Y como segundo parámetro, necesitas pasar el estado, que es una función que devuelve un objeto. Y luego getters y acciones, por supuesto sin mutaciones, acciones por supuesto, sin mutaciones, pero acciones que cambian el estado de la tienda usando solo esto. Puedes usar una sintaxis de composition API también. Es algo similar al script de configuración, pero lo importante que debes recordar es que necesitas devolver propiedades, getters y acciones en la parte inferior de la función, de lo contrario no funcionará. Pero si recuerdas esto, puedes simplemente definir tus propiedades reactivas, computadas y funciones, y funciona. Es realmente genial.

Ahora, para usar la tienda en tus componentes, necesitas importar store2refs. Store2refs si quieres usar la sintaxis aquí, o simplemente importando la tienda, tu tienda de uso exportada, luego declarando la tienda. Y a partir de ahora puedes usar directamente la tienda, accediendo a las acciones de estado y getters desde aquí. O si quieres usar getters y propiedades reactivas de una manera fácil con variables, puedes definirlas usando una sintaxis computada como esta o como mencioné hace unos segundos, puedes usar store2refs para expandirlas en variables en una sola línea. No necesitas store2refs para acciones porque son funciones simples. Así que puedes llamarlas sin la reactividad. Para Vue.js 2, necesitas importar mapState y mapActions algo similar a Vuex y por supuesto, tu tienda y luego puedes mapear el estado y las acciones para envolver los getters de estado en mapState y acciones, mapActions, por supuesto. Y puedes usar cadenas como lo estábamos haciendo en Vuex en Vuex o puedes mapearlos de esta manera.

Así que ahora es el momento de migrar todo de Vuex a Binia. Pero antes de eso, necesitamos preparar la migración para tener todo ordenado y todo listo para ir. Así que echemos un vistazo a la estructura de la tienda Vuex. Tenemos la tienda con index.js conteniendo la inicialización de Vuex, Importa modules, y la tienda principal y otros modules.

3. Migrando la Definición de la Tienda y las Pruebas

Short description:

Para migrar tu tienda a Pinia, extrae todo en una consola, incluyendo estados predeterminados, getters, mutaciones, acciones y módulos. Compónelos en la definición de la tienda uno por uno sin mezclar la lógica. Usa la función defineStore y una función para el estado predeterminado. Elimina las mutaciones y los módulos. Cambia los getters, mutaciones y acciones para usar 'this' en lugar de 'state' o 'getters'. Las pruebas para el estado permanecen igual, pero para los getters, mutaciones y acciones, usa .call y pasa el estado actual como primer parámetro.

Así que ten en cuenta esta estructura por un momento. Y para la definición de la tienda, te sugiero que cambies ligeramente tu definición de la tienda a esta. Así que extrae todo en una console. Desde los estados predeterminados hasta los getters, mutaciones, acciones y modules. Y luego compónelos en la definición de la tienda para migrarlos uno por uno sin problemas o mezcla de lógica. Lo mismo para el módulo, así que puedes exportar el estado predeterminado, getters, mutaciones y acciones y componerlos en la definición del módulo.

Así que, para migrarlos, solo necesitas cambiar de create store a define store y definir el nombre de la tienda y usar una función para el estado predeterminado. Y todo lo demás es más o menos lo mismo. Solo necesitas eliminar las mutaciones y los modules porque ya no hay más modules para pinyin. Y luego puedes cambiar tu estado. Bueno, no realmente porque el estado es solo un objeto así que puedes dejarlo como estaba y funciona. Solo necesitas cambiar los getters porque, bueno, si estabas usando getters así, hay que cambiar. La sintaxis es la misma. Pero si estabas usando funciones, bueno, estas funciones no necesitan recibir parámetros porque pueden acceder a este contexto, accediendo a otros getters o al estado de la tienda. Así que funciona con esto, no con state o getters. Lo mismo para las mutaciones y las acciones.

Así que, bueno, las mutaciones se convierten en acciones. Y luego si estaban usando un state para acceder a la tienda o getters o otras mutaciones, solo necesitas usar esto y funciona. Lo mismo para la acción, no necesitas pasar el contexto como primer parámetro, solo necesitas usar esto. Y de nuevo es algo genial. Ahora, ¿qué pasa con las pruebas? Bueno, si no encuentras pruebas, por supuesto, las pruebas no fallarán, pero si estás escribiendo pruebas, necesitas migrarlas también. Así que, bueno, si extrajiste la lógica, como mencioné antes, la prueba sobre el estado no cambia porque solo prueban un objeto y esperan que sea como estás esperando. Pero si estás testing getters o mutaciones o acciones, ahora necesitas usar .call para llamar a los getters o acciones, y pasar como primer parámetro del método call, tu estado actual, para probarlo y actuar sobre él. Lo mismo para las mutaciones y las acciones, solo pasa el estado en la llamada, simulando quizás funciones o el estado de la tienda, y puedes usarlo como tu contexto de tienda. Así que vamos a ver un par de ejemplos aquí. Esta es la migración de la prueba de estado. Así que solo necesitas esperar que el estado predeterminado sea igual a lo que necesitas. Para los getters, esto no cambia porque, bueno, lo estábamos usando de la vieja manera. Así que pasando el estado como primer parámetro. Pero en este caso, estamos pasando el code con el contexto.

4. Pruebas del Comportamiento Real de la Tienda

Short description:

Para probar una tienda real para un comportamiento real, necesitas crear una instancia de Binya en tu archivo de prueba y definir la tienda. Úsalo como lo harías en componentes o en tu aplicación. Sin embargo, crear una instancia de Binya antes de cada caso de prueba puede consumir mucha memoria.

Lo mismo para las mutaciones. Así que definiendo el estado y pasándolo a la función. Y por supuesto, lo mismo para las acciones. Así que escucha la llamada a otra acción, y llámala, y espera que haya sido llamada. Y bueno, al final, si quieres probar una tienda real para un comportamiento real, puedes hacerlo de esta manera. Necesitas crear binya, y establecer la binya activa en tu archivo de prueba, en el antes de cada caso de prueba. Y en el caso de prueba, puedes definir la tienda, y usarla como la estás usando en los componentes o en tu aplicación, y funciona. No te sugiero esto, porque estás creando una instancia completa de binya antes de cada caso de prueba, por lo que consume bastante memoria. Pero si quieres probar la tienda real, puedes hacerlo de esta manera.

5. Migración de Componentes y Pruebas de Componentes

Short description:

Necesitamos importar useStore de la tienda correcta y usarlo con propiedades calculadas o store2Fs. Elimina mapState, mapGetters, mapMutation de Vuex y usa mapState y mapAction de vigname. Importa useStore y usa mapState, pasando useStore como primer argumento y una lista de cadenas para propiedades y getters en mapState y funciones en mapActions. Instala Pina testing para probar correctamente los componentes usando Pina. Usa createTestingPina para simular acciones y sobrescribir los valores de los getters en las pruebas. Se proporcionan ejemplos de pruebas de componentes con Vue 3 y VTest.

Por último, pero no menos importante, queremos migrar nuestros componentes. Como mencioné, necesitamos importar useStore de la tienda correcta, y usarlo de esta manera. Así que con propiedades calculadas, o con store2Fs en una sola línea. Y simplemente importa la función así desde la tienda y úsalas.

Para Vue.js también, necesitamos eliminar mapState, mapGetters, mapMutation, y así sucesivamente de Vuex y usar mapState y mapAction de vigname. Necesitamos importar useStore y usar mapState pasando como primer argumento el useStore que necesitamos. Y el segundo argumento, una lista de cadenas para propiedades y getters en mapState y funciones en mapActions. Lo mismo para los modules de espacio de nombres. Así que ya no necesitamos crear pañales de espacio de nombres. Solo necesitamos importar el estado actual y usarlo de la misma manera.

Ahora es el momento de probar nuestros componentes usando Pina. Así que si quieres hacer una prueba de componentes adecuada testing para componentes usando Pina, necesitas instalar Pina testing. Esta es una gran dependencia que expone esta función createTestingPina que necesitas llamar. Si usas vtest, necesitas pasar createSpy como argumento definiendo lo que createPina necesita usar para simular tus acciones, por ejemplo. Lo veremos en un momento. Y también puedes pasar el estado inicial. Este es el nombre de la tienda que quieres simular o definir. Y estos son sus valores. Así que vamos a inspeccionar createTestingPina. createTestingPina simula automáticamente todas las acciones. Así que puedes unit test la tienda y los componentes por separado para comprobar el comportamiento de los componentes y el comportamiento de la tienda, pero de manera separada. Y por supuesto, te permite sobrescribir el valor de los getters en las pruebas. Ten en cuenta que esto no funciona con Vue.js 2 y Jet porque no puedes sobrescribir los getters en Vue.js 2, pero en Vue.js 3 es genial. Así que no tienes que trabajar en torno a la configuración del estado de la tienda predefinido para hacer el getter en el valor que necesitas, solo necesitas simular el getter y sobrescribir sus valores. Es impresionante. Así que veamos un par de ejemplos en las pruebas de componentes. Un ejemplo con Vue 3 y VTest es así. Así que antes de cada caso de prueba, necesitamos crear nuestra Pina de testing pasando la función de simulación para el create spy. Y por supuesto, si quieres un estado inicial, entonces puedes encontrar tu tienda así, luego puedes montar superficialmente tu componente pasando Pina como plugins globales. Lo mismo para Vue.js 2 y Jest.

6. Migrando Pruebas y Tareas Finales

Short description:

Para migrar tus pruebas, crea una vista local y usa el plugin Pina. Antes de cada caso de prueba, crea la Pina de pruebas y pasa el estado inicial. Al montar el componente, pasa la vista local y Pina. Los getters en Vue.js 2 y Jest no son modificables, por lo que debes establecer el estado correcto. Para establecer el recuento de la tienda, escríbelo o parchea la tienda. Al usar la tienda, impórtala y accede a las propiedades y getters directamente. Importa la tienda y llama a la función de acción actual para commit y dispatch. Vuex y Pinia pueden coexistir, pero migra módulos enteros, no componentes. Para la persistencia de la tienda, suscríbete a los cambios de la tienda o usa un observador. Finalmente, elimina Vuex de main.js, elimina la tienda Vuex y las pruebas, y desinstala las dependencias de Vuex.

Así que solo necesitas crear una vista local, usar tu plugin Pina y antes de cada caso de prueba, crear la Pina de testing, pasando el estado inicial y encontrando la tienda. Y luego al montar el componente, necesitas pasar la vista local y Pina también. Entonces, un rápido repaso, los getters en Vue.js 2 y Jest no son modificables. Así que necesitas establecer el estado correcto para que funcionen como se espera. Así que así, si quieres establecer el recuento de la tienda, puedes escribirlo o simplemente parchear la tienda si necesitas actualizar más propiedades a la vez. Puedes migrar tus pruebas de esta manera.

Así que moviendo create store e importando create testing Pina y new store. Eliminando el create store de Vuex y usando create testing Pina. Y de nuevo, importando el plugin Pina más largo en el shallow mount y probando todo de esta manera. Lo mismo para VJSU, solo importa lo que necesitas, define tu tienda en lugar de la tienda Vuex y pásala a la función shallow o a la función mount y todo debería funcionar. Bueno, sí, no exactamente. Así que hay un par de problemas de migración. Llamémoslos nudos de migración.

Así que si estabas usando la tienda con un enfoque directo como este, ahora necesitas importar tu tienda y acceder a las propiedades y getters usando la tienda y no más uso mágico de la tienda. Lo mismo para commit y dispatch. Si estabas usando commit y dispatch desde cualquier lugar de tu aplicación, ahora necesitas importar la tienda y llamar a la función actual, la función de acción. Luego otra cosa que necesitas recordar es que si estás usando la tienda de esta manera fuera de la pestaña de scripts, bueno, por favor recuerda no escribir esto en la raíz de tu módulo, de lo contrario puedes obtener este error porque no tienes ActivePynea definido. Así que recuerda prepararlo en una función y usarlo así o usarlo en la pestaña de scripts.

Puedes preguntar si Vuex y Pynea pueden coexistir. Bueno, sí, por supuesto, pero al migrar, por favor recuerda migrar módulos enteros y no componentes enteros. Así que necesitas asegurarte de que un solo módulo ha sido migrado antes de pasar a otro módulo solo por orden y simplicidad de migración. Así que pueden coexistir, pero solo tienes un solo módulo de Vuex y ese módulo puede ser migrado a Pynea, pero otros módulos pueden estar en Vuex mientras se migran. Si necesitas persistencia de la tienda, puedes usarla de esta manera en dos formas, realmente, porque puedes suscribirte a los cambios de tu tienda y establecer tu, por ejemplo, almacenamiento local de la manera que prefieras, y puedes restaurarlo cuando la aplicación se haya actualizado usando mystore.state y settings.state, o puedes observar. Puedes usar un observador en tu aplicación y observar los cambios de estado de Pinion y almacenarlos en una variable de almacenamiento local, por ejemplo. Y si necesitas restaurarlo, puedes usar pinion.state.value y establecer su valor.

Ahora hemos llegado al final de nuestra migración. Como tareas finales, necesitamos eliminar Vuex de main.js. Así que solo elimina tu importación y tu uso de la tienda. Y luego podemos eliminar la tienda Vuex y las pruebas. Y por último, pero no menos importante, necesitamos desinstalar las dependencias de Vuex. Así que Vuex y por ejemplo, el plugin CLI de Vue Vuex. Y eso es todo, hemos emigrado de Vuex a Pinia. Ahora te dejo un par de enlaces por supuesto a la documentación oficial de Pinia y dos repositorios con la rama de migración a Pinia, para que puedas revisar y ver lo que necesitas o lo que puedes querer cambiar para migrar de Vuex a Pinia. Y eso es todo, adiós a todos.

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

Network Requests with Cypress
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.
Testing Pyramid Makes Little Sense, What We Can Use Instead
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
Gleb Bahmutov
Roman Sandler
2 authors
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.
Full-Circle Testing With Cypress
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
Test Effective Development
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!
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
Everyone Can Easily Write Tests
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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
How to Start With Cypress
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
Filip Hric
Filip Hric
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.
Detox 101: How to write stable end-to-end tests for your React Native application
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
Yevheniia Hlovatska
Yevheniia Hlovatska
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
API Testing with Postman Workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
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.
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
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.
Best Practices for Writing and Debugging Cypress Tests
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
Filip Hric
Filip Hric
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.