No Más Mocking! Mejora tus Pruebas Para tu Aplicación Nuxt con Pruebas de Contrato

Rate this content
Bookmark

Exploraremos cómo crear sistemas de software más resilientes utilizando técnicas API-first. Al utilizar la herramienta de pruebas de contrato Specmatic y el ejecutor de pruebas Playwright, podemos desarrollar pruebas que aseguren que nuestras aplicaciones Nuxt funcionen perfectamente y se comuniquen correctamente con los Microservicios en los que confían para obtener datos.

Analizaremos más de cerca cómo escribir especificaciones OpenAPI que nos ayuden a documentar nuestras APIs y nos permitan asegurarnos de que funcionen correctamente. Además, podemos utilizar esas especificaciones para generar automáticamente un servidor ficticio, que podemos utilizar para probar nuestra aplicación en un entorno controlado con Playwright.

Las técnicas que te mostraré te ayudarán a escribir pruebas que te permitan iterar rápidamente sin temor a regresiones.

Resultados del aprendizaje:

1. Conocerás los principios básicos de las Pruebas de Contrato y cómo también ayudan a impulsar nuestras pruebas de extremo a extremo.
2. Sabrás optar por las Pruebas de Contrato al trabajar con Microservicios y BFFs, la siembra de la base de datos al usar Nuxt con una base de datos, y la simulación al tratar con SPAs.
3. Conocerás los pasos para crear tu primera especificación OpenAPI e integrar Specmatic con Playwright o Cypress, y estarás deseoso de aplicar esta técnica en tus proyectos.

Markus Oberlehner
Markus Oberlehner
21 min
25 Apr, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Una aplicación de una sola página utiliza una capa BFF en el lado del servidor para simplificar la autenticación y la personalización de datos. La prueba de una arquitectura basada en BFF implica pruebas de contrato y el uso de herramientas. Surgen desafíos al simular solicitudes de servidor a servidor en una arquitectura de lado del cliente y de lado del servidor. Se deben escribir pruebas separadas para los componentes de lado del cliente y de lado del servidor, con pruebas de contrato para garantizar la compatibilidad. Las pruebas de integración para el front-end y el lado del servidor se pueden realizar reemplazando los microservicios con un sub-servidor.

Available in English

1. Construyendo una Aplicación de Página Única con Capa BFF

Short description:

Hace un par de años, mis colegas y yo construimos una aplicación de página única que obtenía datos de microservicios. Si bien las pruebas eran fáciles, obtener datos directamente de los microservicios era complicado. Para solucionar esto, agregamos una capa BFF en el lado del servidor, lo que permitió que la aplicación del lado del cliente obtuviera datos del BFF. Este enfoque simplificó la autenticación y la personalización de datos sin depender del lado del cliente.

Hace un par de años, mis colegas y yo tuvimos que construir una nueva aplicación desde cero. Y decidimos que queríamos construir una aplicación de página única. Entonces nuestra arquitectura se veía más o menos como lo que puedes ver aquí. Teníamos nuestra aplicación, que era una aplicación de página única, que obtenía sus datos de un par de microservicios.

Y hasta aquí todo bien. Esto tenía algunos beneficios, como que las pruebas eran muy fáciles. Para probar toda nuestra aplicación de forma aislada, simplemente podíamos simular todas las solicitudes a los microservicios. Pero también había algunas desventajas con esta arquitectura, porque nos dimos cuenta de que en algunos escenarios, obtener los datos directamente de los microservicios era bastante complicado, porque los microservicios no estaban adaptados a las necesidades de nuestra aplicación de página única. Y por eso decidimos adaptar un poco nuestra arquitectura.

Entonces lo que hicimos fue, en lugar de tener solo una aplicación del lado del cliente, también agregamos una capa del lado del servidor, una capa BFF. Y ahora nuestra aplicación de página única del lado del cliente no obtenía los datos directamente de los microservicios, sino que la parte del lado del cliente de nuestra aplicación obtenía sus datos del BFF. Y el BFF hacía solicitudes a los servicios. Y esto tenía algunos beneficios. Principalmente, la autenticación era más fácil, por ejemplo, porque no teníamos que exponer un token de acceso al lado del cliente. Y también podíamos adaptar los datos que obteníamos de los microservicios a las necesidades de la aplicación del lado del cliente, sin tener que hacer mucha lógica de conversión de datos en el lado del cliente.

2. Pruebas de una Arquitectura basada en BFF

Short description:

Probar una arquitectura basada en BFF tiene sus pros y contras. En esta charla, exploraremos las diferencias en las pruebas entre arquitecturas monolíticas, aplicaciones de página única y aplicaciones de pila completa con microservicios. Discutiremos el uso de un enfoque API-first con pruebas de contrato y herramientas como Playwright y la función de servidor simulado de Spagmatic. Además, compararemos técnicas de escritura de pruebas, incluyendo la siembra de la base de datos, para aplicaciones monolíticas.

Pero también había una desventaja, porque ahora no podíamos probar toda nuestra aplicación, porque al probar nuestra aplicación con Playwright, por ejemplo, solo podemos simular las solicitudes realizadas desde el lado del cliente en el navegador hacia el lado del servidor. Así que solo podíamos simular esas solicitudes, pero ya no podíamos simular esas solicitudes, porque esas solicitudes se realizan desde el lado del servidor hacia otras aplicaciones del lado del servidor. Y esto no es posible con herramientas como Playwright y Cypress.

Así que había algunos pros y algunos contras en este enfoque. Y en esta charla, quiero mostrarte cuáles son las diferencias en cuanto a las pruebas cuando tenemos, por ejemplo, una arquitectura monolítica, aplicaciones de página única como vimos en la primera diapositiva, y también aplicaciones de página única o aplicaciones de pila completa en combinación con microservicios, como vimos en la segunda diapositiva. Veremos cómo podemos utilizar un enfoque API-first con pruebas de contrato para solucionar el problema que enfrentamos al cambiar a una arquitectura basada en BFF, al no poder simular más la solicitud de los microservicios. Y veremos cómo podemos hacer esto utilizando Playwright y una herramienta llamada Spagmatic y la función que tiene, que es una función de servidor simulado.

Pero primero, veamos cómo escribimos pruebas cuando tenemos una aplicación monolítica para que podamos ver las diferencias entre las diferentes arquitecturas. Entonces, con una aplicación monolítica, típicamente una LRL, un Ruby on Rails, o por ejemplo una aplicación Nuxt o Next.js que se comunica con una base de datos. Definiría una aplicación monolítica como aquella que tiene una capa de UI, lógica de negocio y una capa de datos todo en uno. Con ese tipo de aplicaciones, podemos utilizar una técnica como la siembra de la base de datos para escribir pruebas o tener los datos correctos para nuestras pruebas.

3. Pruebas de Diferentes Arquitecturas de Aplicaciones

Short description:

Con aplicaciones monolíticas, las pruebas se pueden ejecutar sembrando la base de datos con los datos requeridos. Las aplicaciones de página única pueden simular fácilmente las solicitudes a los servicios. Sin embargo, cuando hay una parte del lado del servidor dentro de una aplicación de front-end que obtiene datos de microservicios, surge un desafío al simular solicitudes de servidor a servidor.

Por ejemplo, aquí puedes ver que tenemos una prueba para una aplicación monolítica. Y para ejecutar la prueba, sembramos la database de donde la aplicación obtiene sus data con un conjunto específico de data para que todo esté configurado para ejecutar nuestras pruebas. Y una prueba podría verse así. Este es un ejemplo de LRL donde tenemos una función auxiliar de siembra y podemos crear una clase de siembra de elementos, por ejemplo. Durante esta charla, utilizaré el ejemplo de una aplicación de lista de compras. Imagina que tienes una aplicación de lista de compras que muestra los elementos en la lista de compras. En este escenario, podrías tener una clase de siembra de elementos y sembrar tu database con algunos elementos que están en la lista de compras de un usuario específico. Hasta aquí todo bien. Así es como funciona típicamente con aplicaciones monolíticas. Pero ¿cómo funciona con aplicaciones de página única? Como vimos antes, con aplicaciones de página única, podríamos tener una SPA y podemos escribir una prueba para esta SPA. Y esta SPA obtiene sus data de servicios, de uno o varios microservicios, por ejemplo. Y además, no hay ningún problema al testing porque simplemente podemos simular todas las solicitudes que se realizan a los servicios. Así que podemos probar esta aplicación de página única de forma aislada, lo cual podría verse así.

4. Pruebas de Interacción Cliente-Servidor

Short description:

Una prueba para una aplicación de página única escrita con Playwright puede interceptar las solicitudes del navegador al microservicio y devolver directamente una respuesta específica. Al tratar con una arquitectura de cliente y servidor, nos enfrentamos al desafío de simular solicitudes de servidor a servidor. Para abordar esto, podemos escribir pruebas separadas para los componentes del lado del cliente y del lado del servidor, pero también debemos probar la interacción entre ambos. Las pruebas de contrato son un enfoque recomendado para garantizar la compatibilidad entre la aplicación y los microservicios.

Entonces, una prueba para una aplicación de página única escrita con Playwright podría verse como lo que puedes ver aquí. Tienes esta función auxiliar de ruta de página proporcionada por Playwright, que podemos usar para interceptar todas las solicitudes que se realizan desde el navegador a un microservicio, por ejemplo. Entonces, si se realiza una solicitud a slash API slash items, le decimos que la solicitud no debe pasar al microservicio real. En su lugar, devolvemos directamente, por ejemplo, un único elemento de la lista de compras.

OK, eso fue para las aplicaciones monolíticas y de página única. Pero ahora, ¿qué pasa con una architecture que, como te mostré antes, tiene una parte del lado del cliente y también una parte del lado del servidor dentro de una sola aplicación, como es el caso de, por ejemplo, Next.js o Next.js, o también cuando tienes tu propia aplicación de página única con un back-end personalizado para el front-end, por ejemplo, y microservicios. Esto es importante aquí. Como vimos con la aplicación monolítica y también con las aplicaciones de página única sin una parte del lado del servidor, podemos utilizar diferentes técnicas. Pero en este caso especial, donde tenemos una parte del lado del servidor dentro de nuestra aplicación de front-end y microservicios, y obtenemos nuestros datos de los microservicios, necesitamos o nos enfrentamos a un problema.

Una architecture podría verse así, donde tienes tu aplicación Next.js con tus componentes del lado del cliente, como tus elementos de vista, y también una parte del lado del servidor, que típicamente son tus rutas de API en una aplicación Next.js. Y tu código del lado del cliente obtiene datos del lado del servidor, de las rutas de API en el ejemplo de Next.js. Y esta parte del lado del servidor obtiene sus datos de los microservicios. Entonces, como dije, aquí nos enfrentamos a un problema porque tenemos dos tipos de solicitudes. Tenemos solicitudes del navegador al servidor, que podemos ver aquí desde la parte del lado del cliente hasta la parte del lado del servidor. Pero también tenemos solicitudes de servidor a servidor desde nuestras rutas de API a uno o varios microservicios. Y al escribir pruebas, solo podemos simular esas solicitudes, pero no podemos simular esas solicitudes aquí desde el lado del servidor a los servicios. Lo que podríamos hacer, una solución alternativa que podríamos elegir usar, es escribir pruebas para las piezas separadas.

No tenemos una prueba para toda nuestra aplicación Next.js o para una función de toda nuestra aplicación Next.js, pero tenemos pruebas separadas para la parte del lado del cliente y otra prueba para la parte del lado del servidor o la pieza del lado del servidor de la aplicación. Y esta es una decisión válida que podemos tomar. Podemos optar por escribir pruebas para las diferentes piezas, pero hay un problema con esto. Porque cuando seguimos este camino, también debemos asegurarnos de que también probamos la combinación de estas dos partes para probar el cruce de fronteras entre el lado del cliente y el lado del servidor. Porque si no hacemos esto, aunque podríamos tener una cobertura de prueba perfecta porque tenemos pruebas para el código del lado del cliente y pruebas separadas para el código del lado del servidor, no podemos estar seguros de que esas dos piezas funcionen juntas correctamente si no tenemos una prueba que se encuentre entre el lado del cliente y el lado del servidor.

Y podemos tener una prueba así. Por ejemplo, pruebas de contrato, pruebas de integración, hay diferentes formas en las que podemos lograr esto. Y las pruebas de contrato, como también se menciona en el título de esta charla, son una buena manera de hacerlo. Y de hecho, para esta frontera aquí, recomiendo encarecidamente utilizar pruebas de contrato. Entonces, para la frontera entre nuestra aplicación y los microservicios, no queremos tener una sola prueba que pruebe, o tal vez solo unas pocas, pruebas reales de extremo a extremo. Pero la gran mayoría de las funciones, no queremos probarlas de manera que probemos todo el sistema, incluidos todos los microservicios. Pero queremos tener pruebas separadas para nuestra aplicación NUXT y para nuestros servicios. Y aquí, podemos utilizar pruebas de contrato para asegurarnos de que esas dos piezas también funcionen juntas y no solo de forma aislada.

5. Pruebas de Integración para el Front-End y el Lado del Servidor

Short description:

Para la aplicación de front-end, sugiero tener una sola prueba para la integración entre los componentes del lado del cliente y del lado del servidor. Tanto los microservicios como la aplicación NUXT se consideran piezas únicas de lógica útil. Para probar toda la aplicación NUXT, incluyendo ambos lados, podemos reemplazar los microservicios con un sub-servidor.

Pero para nuestra aplicación de front-end, creo que las cosas son diferentes. Aunque podríamos usar pruebas de contrato aquí también o alguna otra técnica, creo que porque esas dos piezas trabajan juntas para proporcionar una funcionalidad única a una user interface para nuestros usuarios. Creo que deberíamos tener solo una prueba para ellas porque, en mi opinión, deberíamos estar testing básicamente la interfaz pública de una única pieza de lógica útil. Y un solo servicio, un microservicio, es una única pieza de lógica útil porque puede ser utilizado por otros servicios y aplicaciones para obtener data o activar algunas acciones.

Además, la aplicación NUXT es una única pieza de lógica útil, donde creo que deberíamos tener una sola prueba, como podemos ver aquí. Así que en mi opinión, deberíamos tener un par de pruebas que prueben toda la aplicación NUXT, incluyendo las piezas del lado del cliente y las piezas del lado del servidor, solo aisladas de los microservicios. Y la forma en que podemos hacer esto es reemplazando los microservicios con un sub-servidor. En lugar de simular las solicitudes realizadas desde las piezas del lado del cliente, podemos hacer esto reemplazando los microservicios con un sub-servidor.

En lugar de simular las solicitudes realizadas desde las piezas del lado del cliente, podemos hacer esto reemplazando los microservicios con un sub-servidor.

En lugar de simular las solicitudes realizadas desde las piezas del lado del cliente, podemos hacer esto reemplazando los microservicios con un sub-servidor.

En lugar de simular las solicitudes realizadas desde las piezas del lado del cliente, podemos hacer esto reemplazando los microservicios con un sub-servidor.

En lugar de simular las solicitudes realizadas desde las piezas del lado del cliente, podemos hacer esto reemplazando los microservicios con un sub-servidor.

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

Welcome to Nuxt 3
Vue.js London Live 2021Vue.js London Live 2021
29 min
Welcome to Nuxt 3
Top Content
Explain about NuxtJS codebase refactor and challenges facing to implement Vue 3, Vite and other packages.
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
Testing Web Applications with Playwright
TestJS Summit 2022TestJS Summit 2022
20 min
Testing Web Applications with Playwright
Top Content
Testing is hard, testing takes time to learn and to write, and time is money. As developers we want to test. We know we should but we don't have time. So how can we get more developers to do testing? We can create better tools.Let me introduce you to Playwright - Reliable end-to-end cross browser testing for modern web apps, by Microsoft and fully open source. Playwright's codegen generates tests for you in JavaScript, TypeScript, Dot Net, Java or Python. Now you really have no excuses. It's time to play your tests wright.
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!

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.
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Vue.js London Live 2021Vue.js London Live 2021
117 min
Using Nitro – Building an App with the Latest Nuxt Rendering Engine
Top Content
Workshop
Daniel Roe
Daniel Roe
We'll build a Nuxt project together from scratch using Nitro, the new Nuxt rendering engine, and Nuxt Bridge. We'll explore some of the ways that you can use and deploy Nitro, whilst building a application together with some of the real-world constraints you'd face when deploying an app for your enterprise. Along the way, fire your questions at me and I'll do my best to answer them.
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.