Pruebas de Calidad de Código

Pruebas de Calidad de Código

Este tipo de pruebas sirven para garantizar que la calidad del código es realmente óptima y que la probabilidad de tener errores en la codificación es mínima (nunca dejarán de existir los bugs pero al menos podemos hacer lo pertinente para disminuir la probabilidad).

Existen varios tipos de análisis de calidad y para cada uno existen diferentes herramientas, por lo que a continuación explicaré generalmente qué tipo de análisis se pueden realizar y con qué herramienta.

Cobertura

Este análisis nos indica el porcentaje que nuestro código desarrollado ha sido probado por las pruebas unitarias. La idea principal es que entre más código probado menor el riesgo de que aparezcan comportamientos indeseados. Cobertura es una herramienta muy usada para este tipo.

Análisis de Línea de Código

Este tipo de análisis nos indica la pulcritud del código y se puede dividir en varios:

 Código repetido: Nos indica el porcentaje de código que se encuentra repetido. Esto es, evita que tengamos la misma funcionalidad repetida en varios lugares en el proyecto y que al encontrar un bug y corregirlo nos falte corregirlo en los demás bloques. También nos ayuda a tener un diseño más estructurado y con mayor cohesión.PMD y Simian son buenas herramientas para esto.

 Código Documentado: Nos ayuda en poder conocer qué porcentaje de nuestro código está documentado para que al generar el Java Doc. sea los más real posible.

 Código comentado: Nos dice el porcentaje del código que se encuentra comentado. Aunque en la práxis este código documentado no afecta, ya que la máquina virtual lo ignora, sí mete ruido y suciedad en el código al debuggearlo. Si en teoría comentamos un código porque actualmente no se va hacer uso del pero en un futuro es probable y no tengamos que recodificarlo, es un hecho que la mayoría de las veces NUNCA descomentamos el código para usarlo, por lo que casi siempre resulta basura. Además, contando que se usa una versionador como Git o Subversion, es más fácil remitirnos a la versión donde el código sí existe, tomarlo y luego copiarlo que andarlo arrastrando siempre comentado e inservible.

Complejidad

Este dato de complejidad nos indica que tan complicado es el código (es la implementación ciclomática de McCabe). Por lo regular la complejidad aumenta cuando el código tiene muchas sentencias IF-ELSE, Loops, Switch, etc. La teoría bajo este análisis es que entre menos complejo es un código, más sencillo es poder entenderle, por lo que será más probable que haga lo que nosotros queríamos que hiciera.

Con un buen "refactoring" este indicativo puede ser controlado bastante eficaz.

Diseño de Clases

Este análisis lo que intenta demostrarnos es la relación que existe entre las clases en diferentes paquetes. La agrupación de clases en paquetes sirve para diferenciar la funcionalidad entre clases. Por ejemplo, se tiene una clase de pojos, otra de controladores, otra de interfaces otra de implementación, otra de constantes y utilerías, etc. Por lo que este análisis nos muestra los paquetes desde los más abstractos a los más concretos, por lo que la mayoría de las relaciones las tienen las clases más concretas. Así que si en nuestro diseño existe algún error, este análisis nos mostrará las relaciones indebidas de una clase concreta que hace uso de una abstracta.

Validaciones de Calidad

Existen varias reglas ya definidas y conocidas las cuales al analizar el código y su funcionalidad pueden caer en este tipo de reglas. Estas pueden ser desde meramente funcionales, estéticas, estándares y hasta críticas con bugs potenciales. Herramientas como Checkstyle, Findbugs o PMD

Por ejemplo: Existe la regla Magic Number, el cual nos indica que estamos haciendo una comparación con un número establecido y la teoría dice que ningún número debe ser definido ya que al analizar el código nos costará trabajo entender el porqué de ese número; así que es más fácil usar una constante con un nombre explícito que mencione el significado de ese número. Al poder disminuir éstas violaciones lo más posible, estaremos garantizando que el código cumple con estándares o convenciones, tiene el menor riesgo de bugs probables y en general buenas prácticas de desarrollo.

Sonar

Sonar es una herramienta que tiene integrado todas estas pruebas de control de calidad por lo que dentro utiliza PMD, Findbugs, Checkstyle, Cobertura y demás herramientas en un lugar centralizado. La ventaja de esta herramienta es que podemos utilizarla para poder realizar estos análisis en un lugar centralizado con reportes generalizados, detallados y con la posiblidad de ir adentrando (drilldown). Existe un plugin para maven, jenkins, eclipse, etc. para poder hacer todos los análisis bajo un mismo criterio que en Sonar asignemos.

¿Qué es PMD?

PMD es una herramienta de calidad de código encargada de validar los estándares de construcción de un desarrollo. Es decir, chequea la sintaxis del código fuente que ha sido desarrollado, encontrando las ocurrencias de un determinado problema que haya sido previamente configurado para ser detectado.

PMD Y CPD (Copy and Paste Detection)

Una de las pruebas que se pueden automatizar con esta herramienta es la detección de trozos de código que hayan sido copiados de un método a otro o en distintas clases. El "copy and paste", es decir, el programar copiando y modificando código existente en lugar de crear soluciones genéricas, es lo que se llama un anti patrón, y su práctica es fuente de numerosos errores.

Para realizar estas pruebas tenemos el plugin de PMD, existente en Maven2 y eclipse, en el que se incluye la utilidad de CPD (Copy and Paste Detection). Para conocer detalles sobre el reporting de PMD consultar el siguiente enlace, donde también se puede encontrar los detalles de cómo invocar al plugin PMD desde cualquier proyecto.

Prueba de Código (Caja Blanca).

Pruebas de Caja Blanca: También suelen ser llamadas estructurales o de cobertura lógica. En ellas se pretende investigar sobre la estructura interna del código, exceptuando detalles referidos a datos de entrada o salida, para probar la lógica del programa desde el punto de vista algorítmico. Realizan un seguimiento del código fuente según se va ejecutando los casos de prueba, determinándose de manera concreta las instrucciones, bloques, etc. que han sido ejecutados por los casos de prueba.

En las pruebas de Caja Blanca se desarrollan casos de prueba que produzcan la ejecución de cada posible ruta del programa o módulo, considerándose

...