Testing sobre APIS
Daniel Montero Senior Consultant

¿Por qué es necesario el testing en APIS?

Para poder hablar sobre el testing en API, lo primero es saber ¿qué es una API?, bueno, una API o Interfaz de Programación de Aplicaciones es un conjunto de definiciones y protocolos que se utilizan para desarrollar e integrar el software de las aplicaciones, permitiendo la comunicación entre diferentes aplicaciones de software a través de un conjunto de reglas.

Las API surgieron en los comienzos de la informática, mucho antes que la computadora personal. En esa época, una API normalmente se usaba como biblioteca para los sistemas operativos. Casi siempre estaban habilitadas localmente en los sistemas en los que operaban, aunque a veces pasaban mensajes entre las computadoras centrales. Después de casi 30 años, las API se expandieron más allá de los entornos locales. A principios del año 2000, ya eran una tecnología importante para la integración remota de datos.

¿Para qué sirve una API?

Una API nos facilita el trabajo a la hora de desarrollar un software y de esta manera se puede ahorrar tiempo y dinero. Por ejemplo, si creamos una web en la que poder consultar el clima actual, en vez de tener que hacer todo el desarrollo para poder obtener información climática precisa, podemos hacer uso de las APIs de meteomatics, la cual, con una simple consulta a sus interfaces, esta nos devolverá la información que requiramos respecto al clima actual. De este modo, muchas veces se evita tener que emplear tiempo y dinero en desarrollar algo que ya existe y está a disposición de otros desarrolladores.

Testing de APIS

El testing en API suele ser un apartado muy olvidado cuando se habla de automatización, pero en realidad su relación coste/beneficio es mucho más alta que la automatización de front-end.

Con las ventajas en el uso de las API, a su vez surgen necesidades como probar requisitos no funcionales como sus tiempos de respuesta o la capacidad máxima de peticiones por segundo que soporta, o requisitos funcionales como validar que el contenido de la respuesta sea el esperado.

Para solventar estas situaciones, existen distintos tipos de testing que pueden aplicar a las APIs como:

  • Testing automatizado
  • Testing de rendimiento

El testing automatizado se encarga de comprobar o validar principalmente la respuesta de la petición, si esta es la esperada y los tipos de datos que se debe recibir por parte de la Interfaz son correctos.

Por otro lado, el testing de rendimiento se encarga principalmente de obtener métricas del sistema y probar la velocidad de respuesta en base a la simulación de múltiples peticiones concurrentes y, de este modo, se ve qué nivel de carga soporta la Interfaz.

Para testear una API, lo primero es conocer los diferentes códigos de status de la petición realizada:

  • 1xx Status Code => Información
  • 2xx Status Code => Petición exitosa
  • 3xx Status Code => Redirección
  • 4xx Status Code => Error por parte del Cliente
  • 5xx Status Code => Error por parte del Servidor

Dentro de cada categoría hay diferentes mensajes de información según el valor de xx, esta información se puede consultar en restfulapi. Para poder hacer pruebas sobre API hay diferentes herramientas que nos permiten realizar esta función, una de las más usadas es Postman.

Aunque para uso personal podemos utilizar la versión gratuita, Postman también cuenta con diferentes licencias de pago que disponen de mejores características como poder recuperar las colecciones eliminadas o tener colaboraciones entre equipos de 4 o más miembros para trabajar sobre las mismas colecciones.

Este programa permite realizar tantas peticiones como se necesiten, además de poder agrupar las peticiones en diferentes colecciones (carpetas) según la API que se quiera probar.

Desde Postman también se puede realizar la ejecución automática de una colección, lanzando así las diferentes peticiones que en la colección se hayan almacenado.

Además, se pueden generar diferentes test dentro de cada petición haciendo uso de la librería interna pm para hacer comprobaciones como, por ejemplo, tipo de dato esperado, valor del Status Code, valor de un campo concreto de la respuesta, tipos de cabecera, etc.

Existe un runner a través de línea de comandos que permite ejecutar las colecciones donde se encuentren las peticiones API guardadas

Para generar scripts, se puede consultar la información oficial de Postman, donde vendrá documentado todo lo referente a la manera de trabajar en el apartado Test dentro de cada petición o colección. Existen otras herramientas que nos permiten hacer testing sobre APIs como SoapUI, pero la más usada suele ser Postman por ventajas como las siguientes:

  • Admite colaboración entre miembros del equipo.
  • Tiene una interfaz mucho más intuitiva y atractiva, lo que hace más sencillo su uso.
  • Posee API Network, que es un repositorio de APIs que permite su acceso directo, así como la posibilidad tanto de documentar como de estudiar su uso. También es posible publicar APIs en este servicio de manera privada, sólo accesible por una determinada organización.
  • El uso de Postman es más extendido, por lo que hay más documentación.
  • El costo de las licencias es más barato que otras herramientas.

Como añadido, existe un runner a través de línea de comandos que permite ejecutar las colecciones donde se encuentren las peticiones API guardadas. Este runner se llama Newman. Este complemento es bastante usado sobre todo cuando hablamos de Integración Continua o CI (del inglés, continuous integration). Permite que, a través de herramientas como Jenkins, se puedan ejecutar las colecciones de Postman de una manera sencilla, además, en la documentación oficial de Postman se encuentra un apartado de cómo hacer la integración de Newman con herramientas de CI.

¿Es realmente necesario el testing en APIs?

Con el paso del tiempo el uso de las APIs es cada vez más habitual en los desarrollos de productos y servicios. Muchas aplicaciones se basan en el uso de estas interfaces para recolectar información de diferentes fuentes y así tener un sistema centralizado en el que poder consultar información; por ejemplo, cuando queremos consultar diferentes tarifas de hoteles, seguros, productos, etc.

Este tipo de páginas que nos ofrecen comparativas entre distintas compañías con el mismo producto al final hacen uso de estas APIs para recolectar información de una manera rápida y eficaz. Por lo tanto, es imprescindible que estas APIs funcionen de manera correcta: sin errores y con un tiempo de respuesta adecuado.

Arquitectura API-First

En muchas ocasiones la API de una aplicación web se considera un elemento secundario, lo cual no es necesariamente un error.

Sin embargo, si lo que se está pensando es un servicio como sistema complejo, en el que existen múltiples puntos de contacto con los usuarios como web, móviles, oficinas de atención al cliente, etc. En ese caso, es conveniente pensar y diseñar la arquitectura de su plataforma centrándose en las APIs que permiten su operación y ahí es donde surge la arquitectura API First.

API First es una arquitectura que trata al usuario de la API como el usuario primario de la aplicación. Esto significa que la API no es vista como una alternativa en el paradigma MVC, sino que tiene la más alta prioridad.

En API-First la arquitectura impone una API completa, responsiva y bien documentada. Haciendo uso de esta arquitectura se ve con mayor facilidad la necesidad e importancia de realizar un testing sobre las APIs dado que al final se garantiza el funcionamiento correcto del núcleo de la aplicación.

En otro artículo comentaremos en detalle cual es el acercamiento correcto para hacer pruebas sobre aplicaciones con arquitectura API-First.