Ejecución de tests unitarios con junit en proyectos ant y su integración en jenkins y sonar para medir la cobertura.

0
13017

Ejecución de tests unitarios con junit en proyectos ant y su integración en jenkins y sonar para medir la cobertura.

0. Índice de contenidos.


1. Introducción

En ocasiones tenemos que desaprender lo aprendido y, en el caso que nos ocupa, acostumbrados a llevar a cabo la gestión de la configuración de
nuestros proyectos con maven, volver a ant es todo un reto. En este tutorial vamos a ver cómo integrar una fase de
ejecución de tests unitarios como una tarea de ant, forzando a que pasen los tests para llevar a cabo el empaquetado.

El objetivo no es más que emular lo que estamos acostumbrados a hacer con el soporte de maven, pero con ant, con lo
que la configuración de los pasos dentro de ciclo de vida es totalmente manual, tenemos que olvidar la configuración de
plugins a la que estamos acostumbrados con maven y configurar los targets de ant necesarios.

Una vez tengamos ese soporte a nivel de gestión de configuración lo elevaremos al entorno de integración continua
de tal modo que veremos como llevar a cabo la configuración del proyecto a nivel de jenkins y sonar.
El objetivo final es medir la cobertura de los tests de junit que se ejecutarán con el soporte de ant en sonar, para
reforzar las métricas de calidad.


2. Entorno.

El tutorial está escrito usando el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.4 GHz Intel Core i7, 8GB DDR3 SDRAM).
  • Mac OS X Lion 10.7.5
  • Ant 1.8.2
  • Sonar 3.5.1
  • Jenkins 1.513
  • Sonar Runner 2.2.2


3. junit con ant.

Lo primero es exponer el contenido de nuestro fichero de ant, nuestro build.xml:

Lo más interesante es el uso que hacemos de la etiqueta <junit que nos permite:

  • definir un classpath para la ejecución de los tests,
  • indicar el formato de salida de los informes de ejecución de los tests, y
  • con <batchtest indicar el path de ejecución de los tests con una expresión.

Con el atributo depends establecemos un orden de ejecución y con haltonfailure=»yes» estamos indicando que si fallan los tests
se pare la ejecución, con lo que, en este caso, no se generará el jar.

Desde la vista de ant de eclipse los targets son los siguientes:

Efectivamente, estamos emulando el ciclo de vida de maven, pero con ant y, como lo hemos planteado, el único
problema que debemos resolver es la gestión de dependencias que nos facilita maven, manualmente con ant.

Las soluciones posibles son las de antaño:

  • mantener las librerías de las que depende a nivel de proyecto, como en el ejemplo que exponemos,
    en el que tendríamos un directorio lib a nivel de proyecto con las librerías, o
  • disponer de un proyecto de recursos o librerías comunes a todos los proyectos versionado en el SCM.

Para el objetivo de este tutorial vamos a presuponer que no disponemos de un repositorio de control de versiones, no solo por el
tema de la gestión de dependencias sino también para su configuración en jenkins.

Si ejecutamos la build deberíamos tener una salida como la que sigue:


4. Integración en jenkins.

Una vez tenemos el soporte de ant para la ejecución de la fase de tests vamos a configurar el proyecto dentro de
nuestro entorno de integración continua comenzando por crear un nuevo job en jenkins.

Como no tenemos el soporte de un SCM, no podemos seleccionar uno, usaremos el directorio de espacio de trabajo local
de jenkins para realizar esta prueba de concepto.

En mi caso he hecho una copia local del proyecto en el directorio /Users/miusuario/.jenkins/jobs/tntconcept
y después he asignado las siguientes acciones:

Con ello, ejecutando una build deberíamos tener una ejecución correcta y una salida por consola de la ejecución como la que sigue:


5. Configuración de sonar.

Para llevar a cabo la configuración de sonar en jenkins primero debemos instalar el puglin en jenkins que nos da soporte para hacer uso de sonar runner.

En la configuración de jenkins seleccionamos un tipo de instalación

Y a nivel de proyecto podemos asignar los siguientes parámetros:

Con estas propiedades no es necesario tener un sonar-project.properties a nivel de proyecto.
Con ello ahora deberíamos tener una salida por consola como la que sigue:

Y accediendo a sonar deberíamos disponer una información como la que sigue:

Casi listo, pero… ¿y la cobertura?, ooooops que no se nos olvide que esto ya no es maven…


5.1. Informes de cobertura con el soporte de jacoco.

Pues si, necesitamos algo más de configuración para generar los informes de cobertura y poder importar esa información en sonar para que forme parte de las métricas.

Sonar utiliza por defecto jacoco para medir la cobertura y lo que podemos hacer es añadir a la tarea de ant de junit el soporte de jacoco para generar un informe de cobertura.

Para ello, debemos modificar nuestro build.xml para que quede como sigue:

Unos sutiles cambios:

  • hemos añadido el atributo debug=»true» a la compilación para que la compilación
    se realice con información de debug,
  • hemos añadido la definición de una tarea importandola del fichero de configuración
    org/jacoco/ant/antlib.xml que podemos encontrar en la distribución de jacoco y
  • hemos envuelto la tarea de junit con la tarea de cobertura de jacoco, generando la salida en el fichero jacoco.exec

Además de lo anterior, debemos añadir las siguientes propiedades a la configuración de sonar runner del proyecto:

Con esta configuración deberíamos tener en la salida por consola las siguientes líneas

Y, por fin, en nuestro dashboard de sonar la información de cobertura:


6. Referencias.


7. Conclusiones.

Sin el soporte de maven todo se hace más tedioso, por lo manual; pero en una arquitectura con una gestión de
la configuración basada en ant, si queremos incluir en el desarrollo el aseguramiento de la calidad con herramientas de
integración contínua y métricas de calidad automáticas, no es más que documentarse y dedicarle tiempo.

Un saludo.

Jose

jmsanchez@autentia.com


8. Extra ball: informes de cobertura con jacoco.

Si, por lo que sea, no disponemos de un entorno de integración continua esto es, no tenemos ni jenkins ni sonar,
podemos generar los informes de jacoco dentro de la propia tarea de junit de ant, añadiendo la siguiente configuración a nuestro build.xml

En el directorio de salida de los informes tendremos disponible los informes de jacoco cada vez que ejecutemos la tarea manualmente.

Dejar respuesta

Please enter your comment!
Please enter your name here