Vuex a Pinia. Cómo Migrar una Aplicación Existente

Rate this content
Bookmark

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

24 min
15 May, 2023

Video Summary and Transcription

Pinia es la biblioteca oficialmente reconocida de gestión de estado para Vue.js, con una API más simple 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. La prueba del comportamiento real de la tienda requiere crear una instancia de Pinia, mientras que la prueba de componentes implica importar useStore y usar mapState y mapAction de vigname. Migrar las pruebas implica crear una vista local y usar el complemento Pinia, y Vuex y Pinia pueden coexistir pero deben migrarse módulo por módulo. La persistencia de la tienda se puede lograr suscribiéndose a los cambios de la tienda o usando un watcher.

Available in English

1. Introducción a Pinia

Short description:

Pinia es la biblioteca de gestión de estado oficialmente reconocida para Vue.js. Tiene una API más simple que VueX, no necesita mutaciones y admite TypeScript sin envoltorios complejos. Pinia 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.

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

Antes de comenzar a migrar todo, veamos una comparación rápida entre VueX y PNIA. Por supuesto, PNIA funciona con Vue.js 2 y 3 con la misma versión instalada. Por lo tanto, no necesitas instalar, por ejemplo, VueX 3 para Vue.js 2 y VueX 4 para Vue.js 3. Solo necesitas instalar la última versión de PNIA disponible. Y, por supuesto, funciona. Además de esto, tiene una API más simple que VueX porque las mutaciones ya no existen. A menudo se percibían como extremadamente verbosas. Y nuevamente, con cadenas mágicas para inyectar y demás, eran un poco difíciles de usar. Así que ahora no es necesario usar mutaciones, solo acciones, pero lo veremos en un momento. Y no necesitas crear envoltorios complejos personalizados para admitir TypeScript porque, por supuesto, siempre se implementa como una función o como un objeto. Así que es perfecto con autocompletado y demás. Ya no hay cadenas mágicas para inyectar, importa funciones, importa métodos y propiedades, llámalos y disfruta del autocompletado. Y no necesitas agregar tiendas dinámicamente 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 están un poco en espacios de nombres, podrías decir. Y puedes usar una tienda dentro de otra y funciona. Simplemente genial.

Así que comencemos instalando Pinia. Pinia puede coexistir con Vuex, por lo que puedes instalarlos juntos.

2. Migración a Pinia y Estructura de la Tienda Vuex

Short description:

Si estás utilizando Vue.js 3 o 2.7, simplemente puedes instalar Pinia. Si estás utilizando Vue.js 2.6, necesitas instalar la API de composición de Vue. Para crear la tienda raíz, importa createPinia 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 al final de la función. Para usar la tienda en los componentes, importa store2refs o la tienda exportada useStore. Para Vue.js 2, importa mapState y mapActions. Ahora, preparemos la migración examinando la estructura de la tienda Vuex.

Eso es todo, pero si estás utilizando Vue.js 2.6, también necesitas instalar la API de composición de Vue porque Pinia funciona con la API de composición. Luego puedes encontrar una tienda raíz de manera básica. Simplemente importa createPinia y úsalo en tu aplicación. O si estás utilizando Vue.js 2.x, también necesitas importar el complemento Pinia para Vue y usar el complemento antes de crear Pinia. Pero si quieres crear la tienda raíz de manera avanzada, necesitas crear un archivo index.js en el directorio de tiendas, importar createPinia y crear la tienda. Es algo similar para Vue.js 2.x. Luego, en tu archivo main.js, puedes importar tu Pinia desde las tiendas y usarlo en tu aplicación. Por lo tanto, todo lo relacionado con Pinia permanecerá en la carpeta de tiendas.

Luego de definir la tienda raíz, llamémosla la instancia de Pinia, necesitas definir al menos una tienda si deseas utilizar una tienda. Esta es la sintaxis para Vue.js 3.x y 2.x también. Por lo tanto, necesitas definir la tienda pasando el nombre de la tienda como primer parámetro, y este debe ser único entre las tiendas. Y como segundo parámetro, debes pasar el estado, que es una función que devuelve un objeto. Luego, los getters y acciones, por supuesto, sin mutaciones, solo acciones, por supuesto, sin mutaciones, pero acciones que cambian el estado de la tienda usando solo 'this'. También puedes utilizar la sintaxis de la API de composición. Es algo similar a la configuración del script, pero lo importante de recordar es que necesitas devolver propiedades, getters y acciones al final de la función, de lo contrario, no funcionará. Pero si recuerdas esto, simplemente puedes definir tus propiedades reactivas, computadas y funciones, y funcionará. Es realmente genial.

Ahora, para usar la tienda en tus componentes, necesitas importar store2refs. Store2refs si deseas utilizar la sintaxis aquí, o simplemente importar la tienda, tu tienda exportada useStore, luego declarar la tienda. Y a partir de ahora, puedes usar directamente la tienda, accediendo al estado, acciones y getters desde aquí. O si deseas utilizar getters y propiedades reactivas de manera fácil con variables, puedes definirlas utilizando una sintaxis computada como esta, o como mencioné hace un par de segundos, puedes usar store2refs para expandirlas en variables en una sola línea. No es necesario utilizar store2refs para las acciones, ya que son funciones simples. Por lo tanto, 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 con mapState y las acciones con mapActions, por supuesto. Y puedes utilizar cadenas como lo hacíamos en Vuex en Vuex o puedes mapearlos de esta manera.

Ahora es el momento de migrar todo de Vuex a Pinia. Pero antes de eso, necesitamos preparar la migración para tener todo ordenado y listo para comenzar. Así que echemos un vistazo a la estructura de la tienda Vuex. Tenemos la tienda con index.js que contiene la inicialización de Vuex, importaciones de módulos y la tienda principal y otros módulos.

3. Migración de Definición de la Tienda y Pruebas

Short description:

Para migrar tu tienda a Pinia, extrae todo en una consola, incluyendo estados predeterminados, getters, mutaciones, acciones y módulos. Compónlos en la definición de la tienda uno por uno sin mezclar la lógica. Utiliza 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 iguales, pero para los getters, mutaciones y acciones, utiliza .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 tienda a esto. Así que extrae todo en una consola. Desde los estados predeterminados hasta los getters, mutaciones, acciones y módulos. Y luego compónlos 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 estados predeterminados, getters, mutaciones y acciones y componerlos en la definición del módulo.

Entonces, 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 módulos porque ya no hay más módulos para Pinia. Y luego puedes cambiar tu estado. Bueno, no realmente porque el estado es solo un objeto, así que puedes dejarlo como estaba y funcionará. Solo necesitas cambiar los getters porque, bueno, si estabas usando getters de esta manera, hay una necesidad de 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 this, no con state o getters. Lo mismo para las mutaciones y acciones.

Entonces, bueno, las mutaciones se convierten en acciones. Y luego, si estaban usando un estado para acceder a la tienda o a los getters u otras mutaciones, solo necesitas usar this y funcionará. Lo mismo para las acciones, no es necesario pasar el contexto como primer parámetro, solo necesitas usar this. Y nuevamente, 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, también necesitas migrarlas. Entonces, si extrajiste la lógica, como mencioné antes, las pruebas sobre el estado no cambian porque solo prueban un objeto y esperan que sea como lo esperas. Pero si estás probando getters, 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 acciones, solo pasa el estado en la llamada, simulando tal vez funciones o el estado de la tienda, y puedes usarlo como el contexto de tu tienda. Echemos un vistazo a un par de ejemplos aquí. Esta es la migración de prueba del estado. 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 forma antigua. Así que pasando el estado como primer parámetro. Pero en este caso, estamos pasando el código con el contexto.

4. Pruebas de Comportamiento Real de la Tienda

Short description:

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

Lo mismo para las mutaciones. Así que define el estado y pásalo 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 se haya llamado. Y bueno, al final, si quieres probar una tienda real para un comportamiento real, puedes hacerlo de esta manera. Necesitas crear una instancia de Pinia, y establecer la instancia activa de Pinia en tu archivo de prueba, en el caso de prueba before-each. Y en el caso de prueba, puedes definir la tienda, y usarla como lo harías en los componentes o en tu aplicación, y funciona. No te estoy sugiriendo esto, porque estás creando una instancia completa de Pinia 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 desde la tienda correcta y usarlo con propiedades computadas o store2Fs. Eliminar mapState, mapGetters y mapMutation de Vuex y usar mapState y mapAction de vigname. Importar useStore y usar mapState, pasando useStore como primer argumento y una lista de cadenas para propiedades y getters en mapState y funciones en mapActions. Instalar Pina testing para probar correctamente los componentes usando Pina. Usar createTestingPina para simular acciones y sobrescribir valores de 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 desde la tienda correcta y usarlo de esta manera. Ya sea con propiedades computadas, o con store2Fs en una sola línea. Y simplemente importar la función de la tienda y usarlas.

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

Ahora es el momento de probar nuestros componentes usando Pina. Entonces, si quieres hacer una prueba de componentes adecuada para componentes que usan Pina, necesitas instalar Pina testing. Esta es una gran dependencia que expone la 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 veamos createTestingPina. createTestingPina simula automáticamente todas las acciones. Por lo tanto, puedes probar por separado la tienda y los componentes para verificar el comportamiento de los componentes y el comportamiento de la tienda, pero de forma separada. Y, por supuesto, te permite sobrescribir los valores de los getters en las pruebas. Ten en cuenta que esto no funciona con Vue.js 2 y Jest porque no puedes sobrescribir los getters en Vue.js 2, pero en Vue.js 3 es genial. Así que no tienes que hacer malabarismos para establecer el estado predefinido de la tienda para hacer que el getter tenga el valor que necesitas, solo necesitas simular el getter y sobrescribir sus valores. Es increíble. Así que veamos un par de ejemplos en las pruebas de componentes. Un ejemplo con Vue 3 y VTest es así. Entonces, antes de cada caso de prueba, necesitamos crear nuestra Pina de pruebas pasando la función de simulación para el espía de creación. Y, por supuesto, si quieres el estado inicial, luego puedes encontrar tu tienda de esta manera, luego puedes montar superficialmente tu componente pasando Pina como plugins globales. Lo mismo para Vue.js 2 y Jest.

6. Migrating Tests and Final Tasks

Short description:

Para migrar tus pruebas, crea una vista local y usa el complemento 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, así que establece el estado correcto. Para establecer el contador de la tienda, escríbelo o modifica 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 completos, no componentes. Para la persistencia de la tienda, suscríbete a los cambios de la tienda o usa un watcher. Finalmente, elimina Vuex de main.js, borra la tienda y las pruebas de Vuex y desinstala las dependencias de Vuex.

Así que solo necesitas crear una vista local, usar tu complemento Pina y antes de cada caso de prueba, crear la Pina de pruebas, pasando el estado inicial y encontrando la tienda. Luego, al montar el componente, debes pasar la vista local y Pina también. Así que, en resumen, los getters en Vue.js 2 y Jest no son modificables. Por lo tanto, debes establecer el estado correcto para que funcionen como se espera. Por ejemplo, si quieres establecer el contador de la tienda, puedes escribirlo o simplemente modificar la tienda si necesitas actualizar varias propiedades a la vez. Puedes migrar tus pruebas de esta manera.

Entonces, moviendo la creación de la tienda e importando createTestingPina y la nueva tienda. Eliminando la creación de la tienda de Vuex y usando createTestingPina. Y nuevamente, importando el complemento Pina más largo en el montaje superficial y probando todo de esta manera. Lo mismo para VJSU, solo importa lo que necesitas, define tu tienda en lugar de la tienda de Vuex y pásala a la función shallow o mount, y todo debería funcionar. Bueno, sí, no exactamente. Así que hay un par de problemas de migración. Llamémoslos obstáculos de migración.

Entonces, 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 de acción actual. Otra cosa que debes recordar es que si estás usando la tienda de esta manera fuera de la pestaña de scripts, 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 envolverlo en una función y usarlo de esa manera o usarlo en la pestaña de scripts.

Puedes preguntarte si Vuex y Pinia pueden coexistir. Bueno, sí, por supuesto, pero al migrar, recuerda migrar módulos completos y no componentes completos. Así que debes asegurarte de que un solo módulo se haya migrado antes de pasar a otro módulo, solo por orden y simplicidad de la migración. Por lo tanto, pueden coexistir, pero solo tienes un solo módulo de Vuex y ese módulo puede migrarse a Pinia, pero otros módulos pueden estar en Vuex mientras se migra. Si necesitas persistencia de la tienda, puedes usarla de esta manera de dos formas, realmente, porque puedes suscribirte a los cambios de tu tienda y establecer tu almacenamiento local preferido, y puedes restaurarlo cuando se actualice la aplicación usando mystore.state y settings.state, o puedes usar un watcher. Puedes usar un watcher en tu aplicación y observar los cambios de estado de Pinia y almacenarlos en una variable de almacenamiento local, por ejemplo. Y si necesitas restaurarlo, puedes usar pinia.state.value y establecer su valor.

Ahora hemos llegado al final de nuestra migración. Como tareas finales, debemos eliminar Vuex de main.js. Así que simplemente elimina tu importación y el uso de la tienda. Luego podemos borrar la tienda y las pruebas de Vuex. Y por último, pero no menos importante, debemos desinstalar las dependencias de Vuex. Así que Vuex y, por ejemplo, el complemento CLI de Vue Vuex. Y eso es todo, hemos migrado de Vuex a Pinia. Ahora te dejo un par de enlaces, por supuesto, la documentación oficial de Pinia y dos repositorios con la rama de migración a Pinia, para que puedas verificar y ver lo que necesitas o lo que quieres 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

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!
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

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