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

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.

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.

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í.

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.

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.