La integración de la Inteligencia Artificial (IA) dentro del proceso de gestión de APIs está permitiendo optimizar los ciclos de desarrollo, reduciendo los tiempos y generando soluciones más robustas.
Una de las funcionalidades donde la Inteligencia Artificial puede aportar valor dentro de nuestro ciclo de vida de gestión de APIs, es en el aseguramiento de calidad, permitiendo generar de forma automática los mocks necesarios con sus correspondientes tests, que permitan asegurar el correcto funcionamiento de una API en base de su especificación.
En este artículo veremos cómo podemos, a partir de una especificación en OpenAPI, generar los archivos necesarios para automatizar el flujo de pruebas de nuestra API.
¿Qué es OpenAPI?
OpenAPI (OpenAPI Specification o OAS) es un estándar abierto mantenido por la OpenAPI Initiative, parte de la Linux Foundation, que se utiliza para describir y documentar un servicio RESTful, permitiendo que humanos y procesos puedan entender las capacidades de dicho servicio.
¿Qué es Wiremock?
Wiremock es una herramienta de código abierto que simula servicios basados en el protocolo HTTP.
Esto nos permite crear respuestas predefinidas (stubs) de nuestras APIs para su posterior integración con las herramientas de API Automation testing.
¿Qué es una colección de Postman?
Una colección de Postman es un conjunto de solicitudes de un servicio basado en HTTP, incluyendo todos los componentes necesarios (parámetros, cabeceras, cuerpo del mensaje, …).
Una característica importante es que nos permite incluir scripts de pruebas a las peticiones para validar el comportamiento de nuestros servicios en función de las respuestas obtenidas.
¿Qué es Newman?
Newman es una herramienta de código abierto que nos permite ejecutar colecciones de Postman desde línea de comandos, así como su integración dentro de un flujo de integración continua.
¿Qué es n8n?
n8n es una plataforma visual que nos permite conectar múltiples fuentes de datos heterogéneas para crear flujos de trabajo automatizados sin la necesidad de implementar código (no-code).
– ¿Te gustaría saber más? Consulta nuestro artículo sobre: Cómo identificar el nivel de madurez de las APIs de tu institución y sus necesidades –
Implementación del flujo de trabajo en n8n
Implementaremos el siguiente flujo de trabajo para automatizar la generación de nuestros tests desde una especificación en OpenAPI:
- Analizar la especificación de nuestra API en OpenAPI mediante la IA de Google Gemini (como podrían ser otras plataformas de IA como OpenAI, Anthropic o Azure AI) para obtener los diferentes paths, métodos y códigos de respuesta
| request
«text»: «Generate json result from the following OpenAPI specification. The output should follow the provided schema. The OpenAPI specification is: {{ $json[‘petstore-swagger’].json }}» |
2. Convertir el resultado en un objeto JSON para poder procesarlo de forma más eficiente
| [
{ «path»: «/pet», «method»: «put», «response_codes»: [ { «code»: «200» }, { «code»: «400» }, { «code»: «404» }, { «code»: «422» }, { «code»: «default» } ] }, { «path»: «/pet», «method»: «post», «response_codes»: [ { «code»: «200» }, { «code»: «400» }, { «code»: «422» }, { «code»: «default» } ] }, { «path»: «/pet/findByStatus», «method»: «get», «response_codes»: [ { «code»: «200» }, { «code»: «400» }, { «code»: «default» } ] }, |
3. Iterar cada tupla path/method/code para obtener un stub de Wiremock que cumpla con la especificación de nuestra API para esa tupla y una colección de Postman, con sus correspondientes scripts de pruebas, que nos permita verificar el correcto funcionamiento de esa tupla en concreto. Para pruebas de performance o cargas más complejas, se pueden complementar con herramientas como JMeter o Gatling según la necesidad.
| { «text»: «I need a WireMock stub for the specified resource, method and response code. The stub needs to respond to JSON based on the OpenAPI definition. I need to include also the input parameters» },
{ «text»: «I need a Postman collection for the specified resource, method and response code. The collection must have a test script to validate the response you previously configured in the Wiremock stub. The Postman collection base_url variable must be defined with the server in the OpenAPI definition. The Postman collection _postman_id attribute must be set to {{ $json.method }}-{{ $json.path }}-{{ $json.response_codes.code }}. The collection does not need a response example. Please, verify that the Postman collection you generate is a valid JSON» } |
4. Convertir el resultado en un objeto JSON para poder procesarlo de forma más eficiente
| [
{ «response»: { «wiremock_stub»: «{\»request\»:{\»method\»:\»GET\»,\»urlPath\»:\»/pet/findByStatus\»,\»queryParameters\»:{\»status\»:{\»equalTo\»:\»available\»}}},\»response\»:{\»status\»:200,\»headers\»:{\»Content-Type\»:\»application/json\»},\»jsonBody\»:[{\»id\»:1,\»name\»:\»doggie\»,\»category\»:{\»id\»:1,\»name\»:\»Dogs\»},\»photoUrls\»:[\»http://example.com/photos/doggie1.jpg\»],\»tags\»:[{\»id\»:10,\»name\»:\»cute\»}],\»status\»:\»available\»},{\»id\»:2,\»name\»:\»kitty\»,\»category\»:{\»id\»:2,\»name\»:\»Cats\»},\»photoUrls\»:[\»http://example.com/photos/kitty1.jpg\»,\»http://example.com/photos/kitty2.jpg\»],\»tags\»:[{\»id\»:20,\»name\»:\»fluffy\»}],\»status\»:\»available\»}]}}», «postman_collection»: «{\»info\»:{\»_postman_id\»:\»get-/pet/findByStatus-200\»,\»name\»:\»Swagger Petstore – OpenAPI 3.0\»,\»description\»:\»This is a sample Pet Store Server based on the OpenAPI 3.0 specification. You can find out more about Swagger at [https://swagger.io](https://swagger.io). In the third iteration of the pet store, we’ve switched to the design first approach! You can now help us improve the API whether it’s by making changes to the definition itself or to the code. That way, with time, we can improve the API in general, and expose some of the new features in OAS3.\\n\\nSome useful links:\\n- [The Pet Store repository](https://github.com/swagger-api/swagger-petstore]\\n- [The source API definition for the Pet Store](https://github.com/swagger-api/swagger-petstore/blob/master/src/main/resources/openapi.yaml)\»,\»schema\»:\»https://schema.getpostman.com/json/collection/v2.1.0/ … |
5. Lanzar las pruebas generadas
Una vez disponemos del stub de Wiremock y la colección de postman asociada, podemos cargarlo en nuestro entorno local y lanzar una prueba.
Cabe mencionar que aunque este proceso se realice manualmente durante este artículo, es un proceso que se puede automatizar de forma sencilla dentro de nuestro pipeline de integración continua, utilizando herramientas como GitHub Actions, GitLab CI o Jenkins:
- Importar la especificación OpenAPI en el API Manager (en nuestro caso estamos utilizando la solución de Gravitee.io)
2. Cargar el stub dentro de la instancia de Wiremock
3. Lanzar nuestra colección de postman (utilizaremos la herramienta de newman)
| newman run postman-collection-petstore-pet-get-200.json –insecure –global-var «base_url=https://api.chakray.local/swaggerpetstore» |
| Swagger Petstore – OpenAPI 3.0
→ Finds Pets by status GET https://api.chakray.local/swaggerpetstore/pet/findByStatus?status=available [200 OK, 591B, 66ms] ✓ Status code is 200 ✓ Content-Type header is application/json ✓ Response is an array ✓ Each item in the array is a valid Pet object ┌─────────────────────────┬──────────────────┬──────────────────┐ │ │ executed │ failed │ ├─────────────────────────┼──────────────────┼──────────────────┤ │ iterations │ 1 │ 0 │ ├─────────────────────────┼──────────────────┼──────────────────┤ │ requests │ 1 │ 0 │ ├─────────────────────────┼──────────────────┼──────────────────┤ │ test-scripts │ 1 │ 0 │ ├─────────────────────────┼──────────────────┼──────────────────┤ │ prerequest-scripts │ 0 │ 0 │ ├─────────────────────────┼──────────────────┼──────────────────┤ │ assertions │ 4 │ 0 │ ├─────────────────────────┴──────────────────┴──────────────────┤ │ total run duration: 109ms │ ├───────────────────────────────────────────────────────────────┤ │ total data received: 161B (approx) │ ├───────────────────────────────────────────────────────────────┤ │ average response time: 66ms [min: 66ms, max: 66ms, s.d.: 0µs] │ └───────────────────────────────────────────────────────────────┘ |
Conclusión
En este artículo hemos creado un flujo de trabajo que nos permite integrar un asistente de inteligencia artificial (Google Gemini) dentro de nuestro ciclo de vida de gestión de APIs, con la finalidad de automatizar el proceso de testing mediante la generación de los tests, a partir de una especificación en OpenAPI.
