Pruebas de Postman y cómo incluirlas en la construcción e implementación de Bamboo

Escribir pruebas unitarias para garantizar que las secciones individuales de una aplicación o servicio se ejecuten correctamente es un proceso profundamente arraigado en el flujo de trabajo de la mayoría de los desarrolladores. Otra forma de prueba que podría decirse que es más difícil de incluir en sus proyectos son las pruebas de integración. Las pruebas de integración te permiten garantizar que todas las diferentes unidades de código que componen tu aplicación puedan trabajar juntas de forma coherente sin ningún problema. Por lo general, esto implica probar una versión implementada del código y, por lo general, se considera que las pruebas de integración requieren mucho tiempo y son difíciles de crear. Una herramienta muy útil que puede ayudarte a crear pruebas de integración es Postman.

Postman proporciona a los desarrolladores un conjunto de herramientas que respaldan todas las etapas del ciclo de vida de las API. El caso de uso más frecuente para un desarrollador consiste en depurar una API que se modificó o rompió recientemente enviando una solicitud al punto final en cuestión. Si bien este ejemplo sin duda tiene un propósito para un equipo de desarrollo, no es más que un pequeño fragmento de todos los beneficios que se pueden obtener al usar Postman. Otra característica muy poderosa pero infrautilizada del conjunto de herramientas de Postman es la capacidad de crear y ejecutar automáticamente una colección de pruebas.

Encuentra a Postman aquí.

Pruebas Postman

Una solicitud típica a un backend alojado localmente mediante la aplicación de escritorio Postman puede tener un aspecto similar al siguiente:

Esta solicitud no es nada compleja; de hecho, es lo más básica posible, pero cumple su función de comunicarse con el backend alojado localmente y devolver una respuesta. Con Postman, podemos crear pruebas elegantes para nuestros puntos finales utilizando unas pocas líneas de código. Supongamos, por ejemplo, que queremos crear una prueba para el punto final especificado anteriormente y asegurarnos de que todas las solicitudes que se le hagan devuelvan un 200 HTTP código de estado. Todo lo que necesitamos hacer es entrar en la pestaña «pruebas» de la solicitud de Postman y empezar a escribir la prueba.

En el lado derecho de la pestaña de prueba hay una lista de enlaces que generan código para facilitar un poco las pruebas a través de Postman. La suite de pruebas Postman incluye un conjunto de funciones útiles, como la configuración de variables de entorno y variables globales para usarlas en los cuerpos de solicitud posteriores, la conversión del tipo de contenido de respuesta y la configuración de las definiciones de objetos de respuesta para que se validen automáticamente. Más información sobre la sintaxis de las pruebas de Postman y cómo crearlas se puede encontrar aquí.

Continuando con esta prueba, volvemos a enviar la solicitud y nos aseguramos de que nuestra prueba sea aprobada.

Ahora que estamos satisfechos con nuestra prueba recién creada, podemos guardar nuestra solicitud junto con su prueba en una colección de Postman. Las recopilaciones permiten organizar las solicitudes en agrupaciones lógicas. Luego, estas colecciones se pueden compartir con otros desarrolladores mediante enlaces que se pueden compartir o exportando la colección a un archivo JSON que luego se puede compartir de cualquier manera. Nos gusta mantener las colecciones de pruebas bajo control de código fuente para que cada desarrollador tenga una ubicación central desde la que extraer las pruebas. También utilizamos enlaces que se pueden compartir para compartir colecciones con los miembros de nuestro equipo de pruebas y productos. De este modo, podemos ofrecer al personal que no es de ingeniería la posibilidad de probar rápidamente los puntos finales de nuestro entorno de desarrollo sin necesidad de comprobar ningún tipo de código ni de servidores voluminosos que se ejecutan localmente.

Entornos de carteros

Antes de pasar a crear numerosas solicitudes y pruebas, puede resultar útil entender cómo funcionan los entornos de Postman. Básicamente, permiten almacenar un conjunto de pares de claves o valores que se pueden utilizar en solicitudes y pruebas. Lea más sobre ellos aquí.

Uno de los puntos importantes a tener en cuenta es que los entornos también se pueden compartir de la misma manera que las colecciones.

Cómo ejecutar una colección de Postman localmente

Con todo esto en mente, ahora podemos repetir el proceso de creación de solicitudes y pruebas para todos los puntos finales de nuestro servidor. Se recomienda crear pruebas que cubran una amplia gama de requisitos, por ejemplo, crear una prueba que garantice que uno de los puntos finales devuelva un cuerpo con ciertos campos de datos. Una vez que el conjunto de solicitudes esté lleno de excelentes pruebas guardadas, configure Postman para ejecutar todas estas pruebas juntas como una colección.

Para ejecutar una colección, localice el «ejecutor» de la prueba que se encuentra en la esquina superior izquierda.

Desde aquí, seleccione la colección y cualquier entorno creado para esa colección. A continuación, ejecuta la recopilación y, si todo va bien, un círculo verde indicará la cantidad de pruebas que han pasado. Más abajo, la ventana muestra información detallada sobre las pruebas y solicitudes individuales, como la duración de cada solicitud y qué declaraciones de afirmación se han realizado correctamente.

Integración de estas colecciones en la construcción y despliegue de Bamboo

Con este increíble conjunto de pruebas para estos puntos finales, ¿no sería fantástico poder integrarlo en el proceso de construcción e implementación de Bamboo? Concretamente, sería genial ejecutar una colección de Postman en una implementación para garantizar que los cambios de código funcionen en el mundo real. Bueno, hay algunas malas noticias y algunas buenas noticias. Desafortunadamente, las pruebas de integración de Postman no se admiten en Bamboo de forma nativa; sin embargo, cuando hay voluntad, hay una manera. Esta «forma» no es exactamente la forma más elegante de realizar pruebas en Bamboo, pero logra el objetivo:

Poder ejecutar una colección de pruebas de Postman contra la implementación de uno de nuestros servicios de backend.

El equipo de Postman desarrolló y lanzó un paquete npm muy útil llamado Newman. Newman permite a los usuarios invocar las colecciones de pruebas de Postman a través de una interfaz CLI y, dado que está desarrollado en node.js, se puede invocar fácilmente durante un plan de compilación o implementación en Bamboo. Sin embargo, Bamboo no admite directamente las pruebas de integración para las implementaciones. La recopilación se puede ejecutar inmediatamente después de la implementación mediante un script para invocar a Newman, pero no hay una forma directa de analizar los resultados y vincularlos a esa implementación. Para superar este obstáculo, necesitamos ensuciarnos un poco las manos.

La solución que implementamos consistía en ejecutar nuestra recopilación Postman durante el plan de implementación, cargar los resultados de las pruebas en un bucket de Amazon S3, invocar un plan de compilación completamente independiente mediante una llamada a la API y, por último, extraer y analizar los resultados de las pruebas en ese plan de compilación. Desde luego, no era lo que teníamos en mente cuando pensamos por primera vez en integrar Postman con Bamboo y el diseño tiene algunas limitaciones, pero funciona.

Aunque es posible activar otro plan de construcción a partir de una implementación exitosa con Bamboo Triggers, hemos optado por no seguir este enfoque. Queríamos asegurarnos de que cada implementación exitosa tuviera nuestras pruebas de recopilación de Postman ejecutadas y analizadas correctamente. Para ello, le dijimos a nuestro segundo plan de construcción dónde encontrar los resultados de las pruebas que debía analizar. Si hubiéramos intentado usar activadores para hacer el mismo trabajo, nos habríamos topado con el problema de no poder decirle a la compilación dónde encontrar los resultados de las pruebas. Podríamos haber especificado una ubicación estática en la que escribiríamos los últimos resultados de las pruebas, pero había algunos escenarios extremos con este enfoque que podrían haber provocado que algunos resultados de las pruebas no se analizaran. Dicho esto, usar activadores para invocar el plan de compilación en lugar de una llamada a la API es una estrategia completamente válida y estoy seguro de que existen soluciones para los problemas antes mencionados.

Configuración de una colección Postman para que se ejecute después de la implementación

Antes de poder comenzar el proceso de configuración de nuestra colección para que se ejecutara después de la implementación de nuestro servicio, necesitábamos asegurarnos de que nuestro plan de implementación tuviera acceso a la colección y a los entornos que queríamos usar. Una forma de lograrlo es almacenar la colección y los entornos en un sistema de control de código fuente. Si lo hace, cree una tarea al principio de la implementación para extraer la colección y los entornos del repositorio remoto. En nuestro caso, decidimos simplificar las cosas y almacenar nuestras colecciones junto con el código con el que interactúan nuestras pruebas de colección. Esto significaba que ya teníamos acceso a nuestras pruebas de recopilación en el plan de construcción, al que precedió nuestro plan de implementación.

En el plan de construcción, retiramos el repositorio de nuestro servicio, ejecutamos nuestras pruebas unitarias y creamos nuestros artefactos. Uno de los artefactos que creamos a partir de nuestra compilación consistía en las colecciones y entornos de Postman que queríamos probar después de la implementación.

En el plan de implementación, agregamos una tarea para descargar este artefacto de la compilación anterior.

Con el acceso a la colección, empezamos a trabajar en la configuración de la ejecución de la colección y las pruebas. Para ejecutar la recopilación en los puntos finales implementados recientemente, creamos una tarea adicional al final de la implementación. La tarea adicional invocaba un script que utilizaba a Newman para ejecutar las pruebas de Postman. Decidimos incluir este script en el artefacto de compilación que contiene nuestra colección Postman para facilitar el acceso.

La forma de configurar el script depende de usted, pero si quiere seguir el enfoque que utilizamos, tendrá que incluir algunas secciones de código. Primero, instala Newman y dile que ejecute tu colección Postman.

Cuando ejecuta Newman, puede especificar la ubicación en la que desea que se almacene el resultado de sus pruebas de recopilación. En el fragmento de código anterior utilizamos la variable $Folder.

A continuación, para cargar los resultados de la prueba, utilice la CLI de AWS. Para asegurarnos de que cada archivo de resultados de prueba se pueda identificar de forma única, optamos por agregar la variable bamboo_deploy_release al final del nombre de cada archivo de resultados de prueba.

Desde aquí, invoca el plan de construcción que analizará los resultados de la prueba. Pasamos la misma variable bamboo_deploy_release para poder identificar y descargar el conjunto correcto de resultados de las pruebas.

Análisis e informe de los resultados de las pruebas de recopilación

Una vez que todo esté configurado, cree el plan de construcción y configúrelo para analizar los resultados de las pruebas de recopilación. Si está familiarizado con Bamboo, será bastante fácil de lograr. En primer lugar, necesitamos crear el plan.

Luego tenemos que configurar el plan y agregarle algunas tareas.

Revisamos uno de los repositorios que contenía un script de shell que creamos para descargar los resultados de las pruebas de recopilación de S3.

Finalmente, usamos JUnit para analizar los resultados de las pruebas.

Si has configurado todo correctamente cada vez que se produzca la implementación, tu recopilación de Postman debería ejecutarse y los resultados deberían publicarse en el plan de creación creado anteriormente.

Un resumen de los eventos ocurridos

Cambio de código en la rama -> Bamboo build comienza con un disparador -> pases de compilación, se crean los artefactos de la colección Postman -> La implementación de Bamboo comienza con un disparador -> La implementación de Bamboo toma artefactos de Bamboo build -> La implementación de Bamboo implementa tu servicio -> La implementación de Bamboo ejecuta tu script de PowerShell de Postman -> la colección de Postman se ejecuta -> los resultados se cargan en S3 -> una compilación de Bamboo separada se activa mediante una llamada a la API -> una compilación de Bamboo separada ejecuta el script de descarga y analiza los resultados de las pruebas de recopilación

Problemas y cosas que podríamos haber hecho mejor

Debido a la naturaleza de la implementación, hubo un pequeño desajuste entre el despliegue del servicio y las colecciones de Postman que lo perjudicaban. Como Bamboo no admite de forma nativa las pruebas de integración, terminamos analizando los resultados de las pruebas en un plan de construcción independiente. Esto era problemático, ya que creaba una división entre la implementación y las pruebas. Si algunas de las pruebas de Postman fallan, el despliegue seguiría siendo marcado como un éxito; en lo que a ella respecta, llevó a cabo todas sus tareas con éxito. Esto puede hacer que el proceso de rastrear la causa raíz de las fallas en las pruebas sea más difícil de lo que debería ser.

A pesar de sus problemas, la solución que implementamos demostró ser beneficiosa, y un buen ejemplo fue el aumento del conocimiento del estado del servicio. Si nuestras pruebas de recopilación de Postman fallan por algún motivo, podemos configurar alertas que notifiquen al equipo de desarrollo asignado. Si se produce esta situación, los resultados de las pruebas de recopilación de Postman ayudan a los desarrolladores a diagnosticar y comprender los problemas presentes. Al ver los resultados de las pruebas de recopilación en Bamboo, un desarrollador puede ver fácilmente qué pruebas han fallado y cuáles han pasado. Sin pruebas de integración como estas, los problemas y errores se vuelven cada vez más difíciles de identificar y resolver.