APIKit + MUnit + Coverage
¿Qué es MUnit?
Esta es la primera entrada en este nuevo blog. Me gustaría comenzar hablando de MUnit. MUnit es un framework de pruebas nativo para aplicaciones Mule. El objetivo fundamental es poder ejecutar pruebas unitarias y funcionales previo al despliegue de las APIs y/o aplicaciones de Mule.
¿Qué es el coverage?
Al ejecutar pruebas con MUnit tenemos a la mano un reporte de coverage que nos proveé de métricas que indican qué tanto de nuestra aplicación de Mule ha sido cubierta por las pruebas (en porcentaje). Estás métricas las podemos ver en tres niveles: aplicación, recursos o flujos. El reporte se genera en formato HTML por defecto, pero podemos generarlo en formato JSON e integrarlo con algunas otras herramientas de reporteo.
¿Qué es APIKit?
Por otro lado, MuleSoft también nos proveé de APIKit. APIKit es una herramienta para construir APIs de tipo REST o SOAP. El input para la herramienta es la especificación de las APIs basado en cualquiera de los siguientes lenguajes de modelado: RESTful API Modeling Language (RAML) en sus versiones 0.8 y 1.0. O bien, Web Service Description Language (WSDL).
La ventaja de utilizar APIKit es que automáticamente nos ayuda a generar flujos de Mule que corresponden a las operaciones o métodos definidos en el RAML o en el WSDL. Como desarrollador, lo que restaría es implementar cada una de esas operaciones.
Códigos HTTP de Respuesta
Por default, APIKit nos genera flujos que corresponden a cada operación definida en el contrato de las APIs. Sin embargo, para las RESTful APIs, también nos genera el manejo de excepciones común para este tipo de APIs. La herramienta genera flujos para los siguientes escenarios, donde deberíamos devolver un código HTTP de error.
No es la intención de esta entrada explicar los códigos de HTTP, pero vamos a dar una descripción general de estos para que haya un mejor entendimiento al momento de estar escribiendo las pruebas con MUnit.
400 - Bad Request
El consumidor de la API envió algo de forma incorrecta.
404 - Not Found
El recurso que solicita el consumidor no existe (no se encuentra).
405 - Method Not Allowed
El consumidor está utilizando un metodo no soportado por esa URI.
406 - Not Acceptable
El consumidor solicita un formato determinado (encabezado Accept) pero el servidor no es capaz de devolver una respuesta en ese formato.
415 - Unsupported Media Type
El consumidor envía una petición con un formato no soportado por el servidor.
501 - Not Implemented
El servidor entiende la petición, tanto la URI como el método son válidos pero no se encuentran implementados.
Para mayor información y detalle acerca de los códigos HTTP:
APIKit, MUnit and Coverage together
Recién en un proyecto de MuleSoft me di cuenta que la mayoría de las APIs no estaban cumpliendo con un porcentaje alto en el coverage. Esto era debido a que todas las APIs utilizan APIKit y no se estaban creando tests de MUnit para probar todo el flujo autogenerado por APIKit. Esto, hasta cierto punto, es normal pues no tiene mucho sentido probar con MUnit algo que es generado por MuleSoft, ya que esto fue previamente probado y todas las APIs que utilizan APIKit tienen el mismo funcionamiento.
Sin embargo, imaginemos que un estándar de desarrollo dentro de una institución es que todas las aplicaciones al menos tengan un 85% de coverage en la automatización de las pruebas. Esto nos lleva a tener que crear pruebas para los processors generados por APIKit para elevar el porcentaje del coverage de la aplicación. Afortunadamente se puede llevar, incluso, hasta el 100% de coverage.
Create Test Suite from API Specification
El primer paso es crear una Test Suite para esa especificación de la API. Esto se hace de una forma muy simple:
- Click derecho en el APIKit Router
- Create Test Suite for <app-name> from API Specification
Los pasos anteriores realizarán el scaffold de la especificación y crearán una Test Suite y dentro de ella, un test para cada flujo definido en la especificación de la API.
Create MUnit Tests for each Error scenario
A partir de aquí, debemos escribir las pruebas de MUnit, no sólo para los flujos definidos en la API, sino también para los escenarios de error. Una vez que entendimos los códigos de HTTP descritos arriba, debemos generar requests a nuestra aplicación para provocar todos y cada uno de los errores definidos en el error handler del flujo principal automáticamente generado por APIKit.
Esto nos llevará a la necesidad de crear un caso de prueba (al menos) por cada error posible en la API.
Coverage Report
Finalmente, al ejecutar las pruebas con MUnit y generar el reporte de coverage, podemos alcanzar el 100% de los processors que forman parte de la aplicación de MuleSoft.
Comentarios
Publicar un comentario