19. sep., 2017

¿ Y tú que sabes de la cobertura de código ?

Hoy en día en nuestros equipos ágiles donde día a día se están empezando a masificar las prácticas de DEVOPS es común escuchar a nuestros compañeros del equipo de Desarrollo hablar sobre la Calidad del Software y nos parece llamativo y extraño sobre todo a los que venimos de la vieja escuela del Testing de Software donde esto no sucedía con frecuencia.

Es claro que con la llegada del desarrollo ágil muchas mejoras en la forma de trabajo se han implementado en los equipos ágiles y el foco sobre la calidad ha logrado que muchos programadores incorporen la idea del testing como algo necesario en el proceso de desarrollo. Por ello aparecen en el paisaje la implementación de prácticas como TDD, BDD, ATDD y los análisis de código estático, entre otras.

Con relación al tema que nos atañe en este artículo que es la cobertura definida como la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. Es decir, si ejecutó las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta de 1000 líneas y solo 400 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 40%.

Ahora bien te preguntarás ¿Cuál es el beneficio que se tiene al medir la cobertura? y más específicamente ¿qué beneficios se tienen al contar con una alta cobertura del código? Una respuesta genérica podría ser que se aumenta la calidad de nuestra aplicación y siendo un poco más concreto que tener una alta cobertura, significa que gran parte de mi código está siendo testeado y por consiguiente podría tener cierta certeza sobre el correcto funcionamiento de mi aplicación. De manera similar medir la cobertura puede ayudarme a detectar código innecesario en mi aplicación, ya que es código que no se ejecuta en ningún caso o identificar si hay código duplicado.

Con su implementación viene otra pregunta aunada que es ¿Qué porcentaje de cobertura es suficiente para estar tranquilo como tester de software? La respuesta no es única, existen distintos criterios y pueden resultar polémicos. Para SimpleCov (una herramienta para medir cobertura en Ruby) se dice que lo ideal es tener una cobertura de al menos un 90%. En el SEI recomiendan cobertura cercana al 80%. Sin embargo si tu aplicación es nueva debes como recomendación manejar un rango de 65% -75%. En algunos de los proyectos trabajados hemos buscado valores cercanos al 80% que es un nivel aceptable en el mercado y este valor es el que sugerimos.

Ahora bien queremos hacer una mención especial y es lo siguiente "Una cobertura del 100% no asegura que mi código no tiene reportes de error o bugs" y esto se debe a que tu código puede estar cubierto en un 100% pero pueden haber casos de excepción o funcionales no incluidos dentro del código actual y esa calidad no te lo puede garantizar solo la cobertura sino hacer un análisis completo a nivel funcional de forma adicional y contemplar desde el inicio requisitos no funcionales y aspectos de desempeño, usabilidad, seguridad, robustez e interoperabilidad. Para esta situación lo que se recomienda es trabajar con TDD y ATDD (sobre todo en funcionalidades críticas de tu aplicación) . Esto es en primer lugar escribir pruebas y en segundo lugar contar con alguna herramienta que permita ir midiendo  la cobertura como complemento.

No esperamos que utilices la cobertura únicamente , de alguna manera es nuestro mensaje final. Pero esperamos que este indicador te sirva en tu día a día como un criterio adicional para medir la calidad del software que realizas o que pruebas y esperamos que sigas nuestras recomendaciones. Si te gustó el artículo compártelo con familiares y amigos y recomienda nuestro sitio www.pmpmedellin.com 

Autor : Ing.Javier León Reyes
Twitter e Instagram: @PMPMedellin