Introducimos control de calidad de código usando sonarqube

Diego Pérez Molinero
6 min readJan 31, 2018

En el capítulo anterior del tutorial, hemos implementado ya nuestro api rest, pero nos falta una parte muy importante, las pruebas.

La idea de este capítulo es introducir en nuestra implementación una batería de pruebas unitarias que cubra la mayor parte posible del código, y también asegurarnos de que la calidad de nuestro código es la adecuada.

Requisitos

Para este capítulo vamos a necesitar tener instalado en nuestro ordenador docker y docker-compose, ya que lo usaremos para arrancar sonarqube, y por supuesto conocimientos básicos de qué es y cómo usarlo.

También recomiendo usar Linux Ubuntu, ya que el tutorial se hace usando este sistema operativo, aunque podéis seguir el tutorial con otro sistema operativo que soporte docker (cualquier otro sabor de Linux o Mac OS)

Si no conocéis docker todavía y el maravilloso mundo de los contenedores, aprovechad a buscar algún tutorial o video por la red. Una vez que lo conozcáis, ya no querréis dejar de usarlo. ;-)

Control de calidad de código

Esta vez vamos a usar una versión dockerizada de sonarqube. En otra serie de tutoriales explicaba cómo usar la versión cloud de sonarqube y cómo integrarlo con github y travis-ci, pero en este caso lo haremos con docker, en nuestro entorno local.

Os dejo el enlace a continuación, por si preferís enganchar el proyecto con sonarcloud, en lugar de usar una versión dockerizada de la herramienta:

Tutorial de creación de entorno colaborativo online

Para usar la versión dockerizada, basta con irnos a la carpeta del proyecto docker-servers, y allí nos encontraremos con el fichero típico docker-compose.yml ya preparado para arrancar sonarqube:

Para arrancar sonarqube, basta con escribir desde esta carpeta:

$ docker-compose up -dStarting sonarqube65_sonarqube_1 ... 
Starting sonarqube65_sonarqube_1
Starting sonarqube65_db_1 ...
Starting sonarqube65_db_1 ... done

Con esto levantaremos la aplicación, que escucha por el puerto 9000.

Transcurridos unos segundos, podemos ir al navegador para comprobar si ha levantado correctamente, y deberíamos ver algo así:

pantalla inicial de sonarqube

Ahora necesitamos instalar sonar-scanner en nuestro sistema. Para ello nos vamos a la siguiente página, donde viene el fichero descargable que necesitaremos en función del sistema operativo que estemos usando:

enlace a sonar-scanner

Ahí nos indican que previamente tenemos que tener instalada una máquina virtual de Java en el sistema (JVM), ya que es necesaria para la ejecución de sonar-scanner.

Para instalar la JVM, seguimos estos sencillos pasos:

$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java8-installer

Y para comprobar si ha tenido exito, hacemos:

$ java --versionjava version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

Para el caso de linux Ubuntu, he descargado el fichero sonar-scanner-cli-3.0.3.778-linux.zip

Lo descomprimimos en la carpeta que queramos, en mi caso lo he dejado en la carpeta de mi usuario ~/Programas/sonar-scanner-3.0.3.778-linux

Dentro nos encontramos la estructura de carpetas siguiente:

bin
conf
jre
lib

Como nos interesa poder ejecutar sonar-scanner desde cualquier sitio, añadimos en el fichero .profile de nuestro usuario lo siguiente:

# Sonar Scanner
PATH="$HOME/Programas/sonar-scanner-3.0.3.778-linux/bin:$PATH"

Importante: Tenemos que salir de la sesión y volver a entrar para que cargue los cambios que hemos hecho en el fichero.

Si todo ha ido bien, después de volver a entrar con nuestro usuario, deberíamos poder ejecutar sonar-scanner desde cualquier punto del sistema.

Para ello, nos vamos a la carpeta del proyecto y ejecutamos:

$ sonar-scanner --version

El resultado ha de ser el siguiente:

Finalmente en la carpeta raíz del proyecto vamos a crear un fichero de propiedades para sonar, de nombre sonar-project.properties, que contendrá lo siguiente:

sonar.projectKey=GameCollectorAPI_v4
sonar.projectName=GameCollectorAPI_v4
sonar.projectVersion=0.0.4-SNAPSHOT
sonar.sources=./
sonar.exclusions=.properties, Dockerfile, *.md, node_modules/**, test/**, coverage/**,*.sh, configuration.js
sonar.tests=test/
sonar.sourceEncoding=UTF-8

En este fichero indicamos el nombre del proyecto, la versión y la localización de los fuentes entre otras cosas.

Ya podemos lanzar sonar-scanner desde la carpeta raíz del proyecto:

$ sonar-scannerINFO: Scanner configuration file: /home/diego/Programas/sonar-scanner-3.0.3.778-linux/conf/sonar-scanner.properties
INFO: Project root configuration file: /home/diego/workspace/proyectos/GameCollectorApiREST_v4/sonar-project.properties
...
...
...
INFO: Task total time: 3.263 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 4.130s
INFO: Final Memory: 46M/308M
INFO: ------------------------------------------------------------------------

Si nos vamos ahora con nuestro navegador al puerto 9000, deberíamos ver el resultado del análisis que ha hecho sonar de nuestro código:

Pantalla principal de sonar con nuestro proyecto ya analizado

Pulsamos en el número 1 que está encima de Projects Analyzed y…

nos muestra el nombre de nuestro proyecto y los resultados. Si seguimos explorando el proyecto, pulsando en el nombre que nos muestra a modo de link…

De momento todo tiene muy buena pinta…partíamos de la versión del API, y no ha encontrado ningún problema.

Vamos ahora al código del API, en el fichero gamesystem.controller.js, concretamente en la función getGameSystems introducimos una variable que no se usa en ningún momento de nombre variableNoUsada, simplemente se declara y ahí queda.

Introducimos una variable que no usamos en ningún momento

Volvemos a ejecutar sonar-scanner y este es el resultado:

sonar nos indica que hay un code smell

Si inspeccionamos el code smell, nos muestra el sitio del código donde a sonar le huele mal.

sonar nos dice que borremos la variable no usada

Borrando esta variable y volviendo a ejecutar sonar desaparecería el problema.

Esto es sólo un ejemplo de lo mucho que sonar puede hacer por nosotros, ayudándonos a realizar un código más limpio y mantenible. También es capaz de encontrar errores que harían que el programa no funcionara (paréntesis sin cerrar, variables no definidas, etc..)

Lo bueno de sonar es que no sólo funciona para javascript, que es el lenguaje en que hemos desarrollado la implementación de nuestro API, sino que puede ser usado para otros lenguajes, por ejemplo:

Lenguajes soportados por sonarqube en el momento de escribir el tutorial

Es una pena que todavía no soporte Go, pero nadie es perfecto ;-)

Aquí os dejo el repositorio de código fuente para que podais trastear con sonarqube y el api rest que tenemos implementado hasta ahora.

Acceso a la quinta parte del tutorial, dónde usaremos ESLint para mejorar nuestro estilo de código.

--

--

Diego Pérez Molinero

Software Architect & defender of clean architecture and domain driven design. Supporter of infrastructure & devops as code into the projects.