Está en la página 1de 4

http://javablog.eliumontoya.

com/home/tipodepruebasparadesarrollodesoftw are Pruebas de Calidad de Cdigo (Raymundo) Este tipo de pruebas sirven para garantizar que la calidad del cdigo es realmente ptima y que la probabilidad de tener errores o bugs en la codificacin es mnima (nunca dejarn de existir los bugs pero al menos podemos hacer lo pertinente para disminuir la probabilidad). Existen varios tipos de anlisis de calidad y para cada uno existen diferentes herramientas, por lo que a continuacin explicar generalmente qu tipo de anlisis se pueden realizar y con qu herramienta.

Cobertura: (Raymundo)
Este anlisis nos indica el porcentaje que nuestro cdigo desarrollado ha sido probado por las pruebas unitarias. La idea principal es que entre ms cdigo probado menor el riesgo de que aparezcan comportamientos indeseados. Cobertura es una herramienta muy usada para este tipo.

Anlisis de Lneas de Cdigo: (Josue)


Este tipo de anlisis nos indica la pulcritud del cdigo y se puede dividir en varios:

Cdigo repetido: Nos indica el porcentaje de cdigo 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 dems bloques. Tambin nos ayuda a tener un diseo ms estructurado y con mayor cohesin.PMD y Simian son buenas herramientas para sto. Cdigo Documentado: Nos ayuda en poder conocer qu porcentaje de nuestro cdigo est documentado para que al generar el JavaDoc sea los ms real posible. Cdigo comentado: Nos dice el porcentaje del cdigo que se encuentra comentado. Aunque en la prxis este cdigo documentado no afecta, ya que la mquina virtual lo ignora, s mete ruido y suciedad en el cdigo al debuggearlo. Si en teora comentamos un cdigo porque actualmente no se va hacer uso de el pero en un futuro es probable y no tegamos que recodificarlo, es un hecho que la mayora de las veces NUNCA descomentamos el cdigo para usarlo, por lo que casi siempre resulta basura. Adems, contando que se usa una versionador como Git o Subversion, es ms facil remitirnos a la versin donde el cdigo s existe, tomarlo y luego copiarlo que andarlo arrastrando siempre comentado e inservible.

Complejidad: (Cob)
Este dato de complejidad nos indica que tan complicado es el cdigo (es la implementacin ciclomtica de McCabe). Por lo regular la complejidad aumenta cuando el cdigo tiene muchas sentencias IF-ELSE, Loops, Switch, etc. La teora bajo este anlisis es que entre menos complejo es un cdigo, ms sencillo es poder entenderle, por lo que ser mas probable que haga lo que nosotros queramos que hiciera. Con un buen "refactoring" este indicativo puede ser controlado bastante eficaz.

Diseo de Clases: (Cob)


Este anlisis lo que intenta demostrarnos es la relacin que existe entre las clases en diferentes paquetes. La agrupacin 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 implementacin, otra de constantes y utilieras, etc. Por lo que este anlisis nos muestra los paquetes desde los ms abstractos a los ms concretos, por lo que la mayora de las relaciones las tienen las clases ms concretas. As que si en nuestro diseo existe algn error, este

anlisis nos mostrar las relaciones indebidas de una clase concreta que hace uso de una abstracta.

Violaciones de Calidad: (Carlos)


Existen varias reglas ya definidas y conocidas las cuales al analizar el cdigo y su funcionalidad pueden caer en este tipo de reglas. Estas pueden ser desde meramente funcionales, estticas, estndares y hasta crticas con bugs potenciales. Herramientas como Checkstyle, Findbugs o PMD Por ejemplo: Existe la regla Magic Number, el cual nos indica que estamos haciendo una comparacin con un nmero establecido y la teora dice que ningn nmero debe ser definido ya que al analizar el cdigo nos costar trabajo enteder el porqu de ese nmero; as que es ms facil usar una constante con un nombre explcito que mencione el significado de ese nmero. Al poder disminuir stas violaciones lo ms posible, estaremos garantizando que el cdigo cumple con estndares o convenciones, tiene el menor riesgo de bugs probables y en general buenas prcticas de desarrollo.

Sonar: (Carlos)
Sonar es una herramienta que tiene integrado todas estas pruebas de control de calidad por lo que dentro utiliza PMD, Findbugs, Checkstyle, Cobertura y dems herramientas en un lugar centralizado. La ventaja de esta herramienta es que podemos utilizarla para poder realizar estos anlisis 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 anlisis bajo un mismo criterio que en Sonar asignemos.

También podría gustarte