Pruebas unitarias

Desde hace unas semanas tenemos en marcha Sonar en nuestra organización para recoger métricas realizando una revisión estática del código. Estamos muy contentos con la implantación de la herramienta y realmente le estamos viendo bastantes posibilidades de cara a un futuro, no obstante es algo que tenemos que tomarnos con prudencia, ya que cada programa es un mundo y no podemos juzgar de antemano y sin un estudio en profundidad de las métricas y de las circunstancias del producto si el mismo a nivel de codificación ha resultado de calidad o no. Hay mucho que trabajar en este sentido, ya que independientemente de lo anterior, una vez analizadas sus bondades y defectos nos permitirá por un lado mejorar la mantenibilidad de los sistemas y la calidad general del producto.

Uno de las cosas que más nos llamó la atención fue que para casi todos los proyectos para los que recogíamos métricas el valor de Cobertura era 0% o lo que es lo mismo, que el 0% del código de gran parte de los sistemas de información de la casa no esta cubierto por pruebas unitarias.

Una vez descubierto esto (no es que hayamos descubierto ninguna maravilla, simplemente es algo que con el día a día no se prestaba atención, pero que sin embargo son tan obvios y llamativos los datos que nos da Sonar que no podemos dejar pasarlo por alto), vamos a meter mano en este tema, porque muchos errores que se detectan en la fase de pruebas del producto o en producción se podían haber detectado previamente con unas sencillas pruebas unitarias, de esta manera mejoraremos la eficiencia de funcionamiento de nuestra Oficina de Calidad, ya que tendrán que dedicar menos tiempo a detectar y reportar este tipo de incidencias y por supuesto reduciremos el número de errores que nos llegan a producción.

De las pruebas unitarias se habla mucho, incluidos los propios proveedores de servicios de desarrollo de software, pero después queda demostrado que del dicho al hecho hay mucha distancia.

La clave de todo está en el equilibrio, si intentamos cubrir con pruebas unitarias todo el código, lo mismo cuesta más el collar que el perro, pero no verificar nada tiene tan poco equilibrio como lo anterior. Por lo menos sería necesario que se verificasen los métodos más conflictivos, comprobando si en función de distintas posibilidades se ejecuta o no el código contenido en los mismos. Como esto dependerá mucho de la complejidad de las aplicaciones, el factor de cobertura será distinto entre ellas, pero una cosa es esa y otra cosa la nada.

About these ads

• calidad del software
• Cobertura
• desarrollo de software
• Gestión de Proyectos
• pruebas unitarias
• Sonar