API REST: entienda el paso a paso para realizar pruebas
Hoy estamos en la onda de los microservicios y con el surgimiento de esta nueva arquitectura, los servicios monolíticos están siendo abandonados. Sin embargo, con tantos servicios de este tipo, surge una cuestión preocupante: las pruebas. ¿Cómo realizar pruebas unitarias de un recurso presente en una API REST? ¿Cómo realizar pruebas de integración de los microservicios? Estas son algunas dudas que surgen en el día a día y tornan la construcción de las pruebas algo desafiante para el desarrollador. Entonces, con el objetivo de ayudarlos, compartiré algunos frameworks, herramientas y consejos de cómo realizar tales pruebas.
¿Qué debo realizar de pruebas en API REST?
Cuando estamos creando nuestro escenario de prueba para API, debemos conocer plenamente su contrato, una API documentada con Swagger ayuda mucho en este momento, pues a través de este sabremos los recursos, cuerpo de mensaje, etc.
Datos de una solicitud:
- Method
- URI
- Headers
- Query Parameters
- Body
Data for a response:
- Headers
- Body
- Status code
Request behavior:
- Validando los datos de retorno.
- Validar los headers de la respuesta
- Validando si la respuesta está de acuerdo.
- Validar si con el content-type modificado el comportamiento continúa igual.
- Validar si la estructura del JSON o XML está correcta.
- Validar si cuando da error el status está de acuerdo con los códigos de error.
- Validar si hay una solicitud con informaciones incompleta, cuál será el comportamiento de la solicitud.
Después de recolectados estos datos ya tenemos un escenario y sabremos cuáles son los comportamientos esperado en nuestra API..
Herramientas de prueba de la API de REST
Después del levantamiento de los principales puntos a ser probados en una API, es necesario escoger la herramienta para la realización de las pruebas. Actualmente el mercado ofrece una variedad de herramientas, pero se debe escoger la que mejor satisfaga al escenario de su proyecto.
Como ejemplo, podemos citar:
En este artículo usaremos Postman para crear las pruebas y Newman para ejecutar las pruebas automáticamente, así que será posible establecer un escenario muy interesante para probar.
Postman/Newman
Postman es un REST Client muy popular entre desarrolladores que necesitan hacer una solicitud HTTP, que ayudan a validar las pruebas realizadas. Tenemos también a Newman que ejecuta colecciones de Postman por línea de comando, lo que facilita el uso de softwares de integración continua ayudando la validación de una API después de la generación de un build.
Escenario de Prueba API Rest
Para mostrar cómo es fácil la utilización de Postman construiremos un paso a paso para probar una API. Esta API es muy simple, ella es un CRUD de Tareas, donde tendremos los siguientes recursos.
Nuestro plan será el siguiente.
Rule Expected result
POST /tasks with missing values return invalid request status HTTP Status 400
POST /tasks when running return creation status and with location in the header HTTP Status 201, Location no header
GET /tasks when running return ok status HTTP Status 200
GET /tasks/{taskid} with valid taskid return task object and ok status Task Object and HTTP status 200
GET /tasks{taskid} with invalid id return status of not found HTTP Status 404
DELETE /tasks/{taskid} with valid id return status of no content HTTP Status 204
Postman
Después de finalizada la construcción del escenario de pruebas, podemos comenzar a utilizar Postman para la creación de los escenarios de pruebas. Para iniciar tenemos dos opciones, importar Swagger o crear una nueva colección.
Import Swagger
Crear una nueva colección
Para generar colecciones de solicitudes de prueba en Postman podemos importar un documento Swagger o generar una nueva colección a través de la propia herramienta. La importación traerá todas las solicitudes descritas en Swagger, mientras la creación de una colección generará solicitudes vacías, siendo necesario que el desarrollador describa los ítems de la colección.
La colección creada con las solicitudes que probaremos
En Postman, tenemos la posibilidad de trabajar con varios ambientes, como Producción o Sandbox, en cada uno de ellos podemos colocar variables para ayuda en las pruebas. Un buen ejemplo es la inserción de la endpoint de la API.
Configuración del Environment.
Para crear las pruebas, seleccionamos el método HTTP (POST, GET, PUT, DELETE, etc) y escribimos la URL de la petición, fíjate que la URL {{uri_task_api}} es una variable de entorno, por lo que podemos probar varios entornos.
Adicione los Headers necesarios, en este caso tenemos que pasar el Header “Content-Type” para especificar que pasaremos un JSON, pero podríamos pasar un Header diferente para probar si API está tratando correctamente el error “media type”.
Cuando estamos realizando una operación de inclusión o edición de datos, debemos llenar el body, este es un ejemplo de un body utilizando JSON. Además de JSON, podemos usar XML, texto, form-data, x-www-form-urlencoded o archivos binarios.
En la pestaña “Pre-request Script” es posible ejecutar scripts antes de realizar una solicitud, en esta imagen estamos creando una variable “createdAt” con la fecha actual, y adicionándola en un ambiente, así podemos utilizar este valor en cualquier lugar en la solicitud.
En la pestaña “Tests” es donde debemos crear los scripts para validar el escenario de prueba, como validar si un status code está de acuerdo con lo previsto, si el Header “location” está presente, entre otras posibilidades. Además de esto podemos recuperar valores para ser utilizados en el futuro, o sea podemos realizar varios scripts, dependerá de su necesidad.s.
Ejecutando las pruebas
Después de crear todos los escenarios, tenemos la posibilidad de hacer la prueba individualmente o a toda la colección. En la prueba unitaria, sólo hay que hacer clic en el siguiente botón:
. Este botón activará su solicitud y validará sus pruebas, y le informará qué pruebas han sido aprobadas o fallidas.
Para llevar a cabo la colección vaya al menú "Runner". Se abrirá una ventana, donde debes seleccionar la colección y el "Environment". Después de eso sólo tienes que hacer clic en el siguiente botón:
. Iniciará todas las peticiones programadas en su colección, y le informará de las pruebas que han pasado o fallado.
Newman
Como fue mencionado anteriormente, tenemos a Newman que ejecuta sus colecciones de Postman, sin embargo, por línea de comando, esto es muy útil cuando usted quiere dejar sus pruebas como un paso de su build. Para usarlo basta exportar de Postman la colección y el ambiente deseado.
Exportar colección.
Export Environment.
Para ejecutar en la línea de comando basta digitar la siguiente expresión:
newman run tasks-api.postman_collection.json --environment task-
environments.postman_environment.json
Después de ejecutarlo, él exhibirá los resultados, con las pruebas ejecutadas y mostrará cuál prueba aprobó y cual falló.
Bien, esta es unas de las formas que usted puede utilizar para probar su API, claro que existen varias herramientas y métodos, basta entender cuál será la mejor para su contexto, y nunca dejar sus APIs sin pruebas.
GITHUB: https://github.com/renanpetronilho/task-api
Nuestra Plataforma de API Management es un hub completo. Con Sensedia, grandes empresas escalan sus operaciones con APIs, con ambientes de pruebas, adaptive governance, api security y mucho más.
Post originalmente publicado en julio de 2017, con actualizaciones menores en 2019.
Inicie su transformación con nosotros
Sensedia está especializada en soluciones de arquitectura basada en eventos, con experiencia desde la creación de estrategias hasta su implementación.
Contenido relacionado
La combinación perfecta de experiencia, personal y plataforma para gestionar sus API.
Su arquitectura digital es más integrada, ágil y escalable.
Acelere la entrega de sus iniciativas digitales a través de APIs, Microservicios e Integraciones menos complejas y más eficientes que impulsen su negocio.
