Como parte de nuestras responsabilidades en Arquitectura y DEVOPS, nos complace anunciar la implementación de las métricas en pruebas de COBERTURA, estas pruebas permiten conocer el alcance de las pruebas unitarias que han sido creadas, esto nos va a ayudar a garantizar que los cambios que se hayan realizado no tengan un impacto dentro del funcionamiento normal y que todos las funciones anteriores o productivas no hayan sido afectadas.
Adicional considerar que todo microservicio NUEVO antes de entrar a producción debemos tener un mínimo del 90% en el porcentaje de pruebas de cobertura, los microservicios antiguos tenemos que trabajar con un plan para la generación de pruebas unitarias.
NOTA: Con esta implementación todo el equipo DEV debe considerar dentro de su planificación la construcción de las pruebas unitarias dentro de sus servicios, ya que en un futuro vamos a implementar varios controles dentro del Gitlab que nos permitirá garantizar el proceso de despliegue limpio hacia QA y Producción.
Pero, ¿cómo funciona?
Las pruebas de Cobertura son un control que nos permite medir la cantidad de métodos y clases que se han probado cuando se crearon las pruebas unitarias, está basado en un porcentaje, es decir, mira todos los métodos de una clase y si una prueba unitaria que se ejecuta llama ese método este se marca como probado.
Cuando ejecutamos la compilación del microservicio o cuando realizamos un mvn verify se crea la carpeta target, dentro de esta carpeta vamos a tener una carpeta de jacoco.
Dentro de esta carpeta vamos a encontrar los reportes y la página web index.html que nos muestra el resultado de las pruebas de cobertura realizada:
Dentro de esta pagina vamos a tener toda la información sobre el reporte de cobertura:
Si damos clic dentro de cada uno de los elementos vamos a ir dentro de cada uno y viendo que métodos nos hace falta probar:
Esto nos ayuda a monitorear que métodos están pendientes de probar en las pruebas unitarias y nos permite enfocar correctamente las pruebas.
Adicional vamos a poder comprobarlo en el proceso de despliegue de cada microservicio en el Gitlab con una etiqueta que va a mostrar la cobertura del código en cada proyecto:
También en los reportes de cada proyecto vamos a ir teniendo una línea histórica que me muestre como incrementa o decrementa la cantidad de cobertura en cada commit.
Ahora, ¿cómo lo implemento?
La implementación del proceso de cobertura es:
En el archivo POM debemos agregar lo siguiente:
Y en los properties debemos agregar lo siguiente para quitar las clases y métodos de los pojos:
Se debe agregar el siguiente archivo dentro de la carpeta Resources:
y también debemos agregar lo siguiente en el POM:
Ok, y todo esto ¿para qué?
Estamos seguros de que con este proceso y las pruebas unitarias aumentará la calidad de desarrollo en nuestros servicios y mejora el tiempo en QA debido a que las pruebas serán únicamente de los procesos nuevos, los métodos anteriores serán probados con las pruebas unitarias que fueron creadas.
Adicional esto nos permite entrar ya en un proceso de actualizaciones continúas debido a que los cambios o refactorizaciones que se generen debido a cambios en los paquetes o alertas de seguridad encontrados en los procesos de seguridad serán más rápidos debido a que al momento de realizar algún cambio se ejecutan las pruebas unitarias y podemos probar todos los escenarios necesarios sin que se convierta en un proceso operativo manual del equipo DEV.
