Cómo ejecutar pruebas de humo de API en tu pipeline de despliegue continuo
Cada año, más empresas de software adoptan una arquitectura de microservicios utilizando Interfaces de Programación de Aplicaciones (APIs), porque las APIs facilitan que los diferentes equipos de un proyecto accedan a los recursos de los demás. Las APIs también permiten que empresas de software o individuos obtengan datos entre sí: por ejemplo, Twitter tiene una API que es utilizada por muchos pequeños negocios para recuperar tuits relacionados con su empresa y mostrarlos en la página web del negocio.
Otra gran ventaja de las APIs es que son más pequeñas que una aplicación monolítica, lo que significa que se pueden desplegar con frecuencia. En la empresa donde trabajo, cada equipo tiene varias APIs y contamos con ocho entornos diferentes a los que desplegamos. Si dependiéramos únicamente de pruebas manuales para verificar que las APIs se hayan desplegado correctamente, tendríamos que ejecutar ocho conjuntos de pruebas por cada lanzamiento de API. Y si desplegamos más de una API a la vez, lo cual sucede a menudo porque nuestras APIs trabajan juntas, podríamos estar ejecutando cientos de pruebas. ¡Y si desplegamos cada dos semanas, esas pruebas se convertirán en una tarea tediosa y repetitiva!
Hemos resuelto este problema configurando pruebas rápidas automatizadas (smoke tests) de APIs que se ejecutan en cada despliegue, en todos los entornos. En este artículo, describo cómo decidimos qué probar y cómo configuramos nuestras pruebas rápidas. Usamos Postman, Newman, Powershell y Octopus para establecer nuestras pruebas automatizadas, así que contaré lo que hicimos con esas herramientas. Sin embargo, estas estrategias podrían adaptarse a cualquier pipeline de despliegue continuo (CD).
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Paso uno: decide qué probar
El objetivo principal de las pruebas rápidas es realizar pruebas simples y de alto nivel para asegurarse de que el despliegue fue exitoso. Este no es el lugar para probar todas las funcionalidades de tu API. Cuando elegimos qué incluir en nuestras pruebas rápidas, esto fue lo que consideramos:
- Establecimos una prueba de “camino feliz” (Happy Path) para cada endpoint, es decir, una prueba que se espera que sea exitosa. Por ejemplo, una solicitud GET para un recurso con un ID específico debería devolver ese recurso. Deberás probar cada endpoint una vez para verificar que cada uno funcione como se espera.
- Si existían grandes variaciones en cómo se usaría un endpoint específico, añadimos una o más pruebas para verificar esas variaciones. Por ejemplo, tenemos una API de recuperación de archivos donde un archivo puede recuperarse de dos maneras distintas. El endpoint es el mismo, pero los cuerpos de las solicitudes son diferentes. Así que añadimos una prueba para cada método.
- Para los endpoints que requerían un cierto nivel de seguridad, añadimos una prueba para validar que una solicitud sin la autenticación adecuada NO devolviera información, y en su lugar devolviera un error de nivel 400.
- No añadimos otras pruebas negativas, como una solicitud POST con datos fuera de los parámetros permitidos, porque consideramos que no eran necesarias para asegurar que la API funcionaba. En cambio, ejecutamos esas pruebas como parte de un conjunto de regresión nocturno.
Paso dos: exporta tus pruebas
Utilizamos Postman para crear nuestras pruebas de API, así que al crear las pruebas, exportamos tanto la colección de pruebas como el archivo de entorno de pruebas a archivos JSON. Para quienes no estén familiarizados con Postman, un entorno de pruebas es un grupo de variables que puede referenciarse en una colección de pruebas.
Paso tres: escribe un script para ejecutar tus pruebas
Postman tiene una herramienta de línea de comandos llamada Newman que puede utilizarse para ejecutar una colección de pruebas, así que eso usamos para ejecutar nuestras pruebas. Creamos un script de Powershell que ejecutaba el comando de Newman.
Paso cuatro: crea un paso de despliegue para llamar tu script
Una vez que el script de Powershell estaba listo, configuramos un paso de despliegue en cada proyecto de despliegue de API de Octopus que ejecutaba el script de pruebas. Si el script fallaba, el despliegue fallaba.
Paso cinco: organiza tus variables
Las variables suelen ser un aspecto a considerar al ejecutar pruebas rápidas en diferentes entornos. Por ejemplo, en tu entorno de QA, tu usuario de pruebas podría tener el ID 340, pero en tu entorno de Staging, el usuario de pruebas podría tener el ID 620. Otro problema con las variables es que, por razones de seguridad, puede que no tengas acceso a contraseñas o llaves en entornos de Producción. Este fue el caso para nuestro equipo, pero afortunadamente Octopus dispone de los valores necesarios para ejecutar nuestras pruebas en Producción. Así que solucionamos el problema haciendo que Octopus pasara los valores necesarios a nuestro script de prueba.
Hubo tres tipos diferentes de variables necesarias para nuestra prueba rápida:
- Tipo 1: Variables que no cambiaban para cada entorno de pruebas, como “firstName”: “Prunella”. Estas variables podían colocarse directamente en el entorno de Postman, por lo que no había nada más que hacer con ellas.
- Tipo 2: Variables que cambiaban para cada entorno de pruebas, pero no necesitaban ser seguras, como “userId”: 340. Estas variables se añadieron como variables de Octopus de esta manera: “smoke.userId”, y el valor de la variable se configuró en cada entorno; por ejemplo, QA se configuró en 340, Staging en 620 y Producción en 450.
- Tipo 3: Variables que cambiaban para cada entorno de prueba y debían mantenerse seguras, como “apiKey”: “b20628a9-3c00-4dad-b38c-0a4d2d85ffab”. Las variables de tipo 3 ya se habían configurado en la biblioteca de variables de Octopus.
Luego utilizamos las variables de la siguiente manera:
- Cuando llamamos al script de Powershell en Octopus, enviamos las variables definidas en Octopus al script.
- En el script de Powershell, aceptamos las variables de Octopus que se enviaban y las asignamos a variables de Powershell.
- Cuando usábamos el comando Newman en el script de Powershell, enviábamos las variables del script al entorno de Postman.
- Newman utilizaba las variables enviadas en el script de Powershell, combinadas con las variables del entorno de Postman para ejecutar la colección de Postman.
Con nuestras pruebas de humo de API ejecutándose en Octopus para cada API y en cada entorno, podemos sentirnos seguros de que cualquier problema grave con el despliegue de una API se detectará de inmediato. Además, podemos probar en entornos de Producción incluso cuando no tenemos acceso a claves API sensibles. Tener pruebas de humo automáticas en los despliegues nos libera para realizar otros tipos de pruebas, como pruebas exploratorias manuales y pruebas de seguridad, así como para escribir más automatizaciones de pruebas para regresiones nocturnas.
Para más guías prácticas, suscríbete al boletín de The QA Lead.
Sigue aprendiendo y escucha este pódcast: CÓMO EL SOFTWARE DE CÓDIGO ABIERTO SIMPLIFICA LA INTEGRACIÓN EN LA INGENIERÍA DE AUTOMATIZACIÓN (CON JAMES WALKER Y SANJAY KUMAR)
