Extendiendo las reglas de SonarQube con Xpath

1
10675

Extendiendo las reglas de SonarQube con Xpath.

0. Índice de contenidos.


1. Introducción

SonarQube permite personalizar las reglas de análisis estático de código para cubrir nuestras necesidades de una manera muy sencilla, bien importando reglas de FindBugs, bien creando las nuestras propias de diversas formas.

Podemos crear reglas para SonarQube en Java o usando directamente xpath definiendo las reglas desde la propia interfaz de usuario de administración.

Pero, ¿xpath no es un lenguaje de consulta de información en formato xml?, si y en este tutorial vamos a ver cómo obtener una representación de una clase java en formato xml, según el formato AST (Abstract Syntax Tree), que permite obtener una representación en forma de árbol del código fuente escrito en un lenguaje concreto de programación.

2. Entorno.

El tutorial está escrito y las pruebas realizadas con el siguiente entorno:

  • Hardware: Portátil MacBook Pro 15′ (2.3 GHz Intel Core i7, 16GB DDR3).
  • Sistema Operativo: Mac OS Mavericks 10.9.4
  • SonarQube 4.3.3


3. AST y SSLR Toolkit.

Como comentábamos AST no es más de una representación en forma de árbol del código fuente de un determinado lenguaje de programación, de modo tal, que cualquier clase java puede tener una representación en xml basada en dicho árbol.

Como tal, dicha información se puede parsear y, como consecuencia se puede consultar.

Podríamos usar un plugin para eclipse que permite acceder a una vista en formato AST de cualquier clase, si bien, el propio equipo de SonarQube ha creado un parser que permite realizar consultas de tipo xpath y proporciona un editor visual, un toolkit, que facilita la generación de una vista AST de una clase java y «jugar» con sentencias xpath sobre las mismas.

La descarga del ssrl toolkit la podemos realizar directamente desde el repositorio central de maven en forma de jar autoejecutable.

La interfaz es la siguiente, podemos pegar el código fuente de una clase en la parte superior izquierda o abrir directamente un fichero. En esa vista podemos modificar a mano el código y pulsando sobre «Parse Source Code» se mostrará a la derecha la representación xml de dicho código.

Se puede navegar sobre el mismo pulsando tanto en la represtanción del árbol de la derecha como en el código fuente de la izquierda estando ambos conectados.

En la parte derecha podemos pulsar sobre la pestaña «XML» para ver esa representación también en formato xml.

Gracias a esta herramienta podremos, haciendo uso de la parte inferior «XPath query», probar nuestras consultas xpath sobre la representación en formato xml de nuestras clases java.


4. noServletsAllowed.

Vamos a definir una primera regla en SonarQube, con una sentencia xpath, que nos permita comprobar la existencia de servlets dentro del código de nuestras aplicaciones; imaginemos que estamos usando un framework MVC y no queremos que nuestros proveedores realicen entregas de funcionalidad fuera de los estándares predefinidos, y la inclusión de un servlet debería justificarse.

Un clase que implementa un servlet podría tener el siguiente código

Con el soporte del SSRL Toolkit, podemos abrir directamente el fichero o pegar su contenido y con el navegador de nodos de la derecha o pulsando directamente en cualquier punto de la clase a la izquierda podemos posicionarnos en el punto concreto del navegador.

Usando la zona de consulta de la parte inferior podemos escribir la sentencia xpath y probar tanto su sintaxis como el resultado de la ejecución de la misma.

Para comprobar que una clase no sea un servlet podemos usar una sentencia xpath que accediendo al identificador de la clase compruebe que no sea de uno de esos tipos, accediendo al nodeValue, que es el contenido textual del nodo.

Una vez disponemos de la sentencia xpath, podemos crear la regla en sonar y lo primero es acceder a nuestro «Quality Profile» y buscar la regla xpath

En la primera búsqueda puede que no lo localicemos y tengamos que pulsar sobre «+ 1 found in inactive rules»

Con ello encontraremos la siguiente regla y podremos pulsar sobre el enlace de la misma.

En la parte inferior debemos pulsar sobre el enlace «Copy rule»

En la siguiente pantalla podremos añadir la información relacionada con la regla a crear en la que incluimos la sentencia xpath dentro del campo correspondiente:

Una vez creada aparecerá en el listado de esta forma

y tendremos que pulsar sobre el checkbox para activarla

Cualquier proyecto que se analice, a partir de ese momento y que tenga asociado nuestro «Quality Profile», podría mostrar un error con el nivel de criticidad asociado

y pulsando sobre el enlace correspondiente que nos lleve hasta el detalle de la violación se mostrará el detalle de la «Issue» con toda la información asignada en la creación de la regla al mismo.


5. noPropertyLocatorInitialized.

Vamos a crear una regla un poco más compleja teniendo en cuenta el mismo código anterior para comprobar que una variable de instancia no sea inicializada de cierta forma; para ello hemos declarado una variable a nivel de clase
incializandola tanto en su declaración como en el constructtor de la clase.

Queremos comprobar que no se lleven a cabo inicializaciones de ese tipo a nivel de clase y para ello, con el soporte del SSLR Toolkit podemos construir una sentencia como esta

Como en el caso anterior creamos una regla copiando la plantilla de reglas de tipo xpath con la siguiente información

La marcamos como activa

Y ahora aparecerá con el nivel de criticidad asociada

Y podemos acceder al detalle de la violación que nos proporciona la información asignada en la creación de la regla.


6. Referencias.


7. Conclusiones.

¿Sientes como la fuerza te acompaña? 😉

Un saludo.

Jose

jmsanchez@autentia.com

1 Comentario

Dejar respuesta

Please enter your comment!
Please enter your name here