El dilema de las herramientas de medición de la cobertura de código

Por Ricardo García Dorta

Las herramientas de medición de la cobertura de tests son esenciales y útiles para entender cuánto de tu código está siendo realmente probado. Estas herramientas, tales como JaCoCo para Java, Istanbul para JavaScript, o Coverage.py para Python, te dan una vista de alto nivel de la cobertura de tus tests, e incluso pueden desglosar la cobertura por línea de código, función o clase.

Sin embargo, utilizadas de una forma errónea pueden hacer que un desarrollo no sea todo lo ágil que debería. En nuestro equipo de trabajo, por ejemplo, este tipo de herramientas, integradas directamente en todas las integraciones continuas de todos los proyectos de la organización, por convención de empresa , hacen que seamos menos ágiles en las entregas, demorándonos varias horas al mes y empobreciendo nuestro código, de ahí nace el dilema de cómo utilizar correctamente estos softwares.

Aunque estas herramientas son valiosas para asegurar la calidad del software, también presentan puntos en contra. El tiempo y los recursos dedicados a configurar, mantener y revisar las métricas de cobertura de los tests, podrían utilizarse para otras actividades que generen valor, como el desarrollo de nuevas características.

Además, la cobertura de los tests no es una medida de la calidad del software. Un código puede tener una cobertura de tests del 100% y aún así tener errores, porque los tests no están bien escritos o no cubren todos los casos de uso posibles. Por otro lado, tener una cobertura del 100% puede ser innecesario o incluso contraproducente. Algunas partes del código pueden ser más propensas a errores o cambios que otras, por naturaleza, y por lo tanto requieren más tests.

Bajo mi experiencia, siempre encuentro el mismo patrón en las organizaciones donde he colaborado. Se toman la cobertura de test como una regla absoluta , es decir, a nivel organizativo, establecen un porcentaje de cobertura sin el cual tu código no puede promocionar al siguiente estado de desarrollo. Esto, para mí, es un error porque genera vicios en los desarrolladores, los cuales te hacen ser menos ágil y empobrece la calidad del código. Vicios como, llenar muchas partes del código de decoradores para excluir esa clase o función de la herramienta, o hacer malos tests los cuales vas a tener que mantener simplemente para contentar a la herramienta.

Sobretodo, el tener estas herramientas como una regla absoluta, genera una falsa sensación de seguridad, la cual puede ser fatal para entregas con riesgo real.

El equilibrio en este dilema puede venir de utilizar las herramientas de cobertura de los tests como una guía, no como una regla absoluta. Pueden ser útiles para identificar áreas de riesgo donde la cobertura de los tests es baja, en partes del dominio donde sí es vital tener tests. Sin embargo, no deberías aspirar a una cobertura del 100% sólo por el bien de la propia cobertura. En su lugar, enfócate en escribir buenos tests para las partes del código que son más críticas o propensas a errores. También, ten en cuenta que cada organización y/o proyecto es un mundo y que no en todos sitios encajan este tipo de softwares. Te recomiendo que lo utilices cuando sea necesario, que no sea un recurso por defecto al crear un nuevo proyecto.

Además, la automatización puede ser útil aquí. Al integrar la generación de informes de cobertura de tests en tu proceso de integración continua, puedes recibir retroalimentación rápida sobre la cobertura del código nuevo, sin invertir mucho tiempo en revisar los informes manualmente, mientras no sea un stopper o un lastre para el desarrollo del producto.

Como action item, podemos cambiar la mentalidad hacia una métrica más realista. ¿Por qué no proponerle a nuestro product owner que en vez de fijarse en el porcentaje de cobertura de código, se fije en la cantidad de bugs reportados en un mes? poniendo, aqui sí, como objetivo en la compañia un número de incidencias máximas al mes. La verdad es que lo veo bastante más preciso con la realidad de un software.

En conclusión, estas herramientas no son un buen indicativo de calidad de código, no las utilicemos como tal. Recuerda que la entrega rápida de valor, no sólo se trata de características nuevas y rápidas. Un código de alta calidad, fácil de mantener y de modificar, puede ofrecer más valor a largo plazo. Por lo tanto, las herramientas de cobertura de los tests, utilizadas correctamente, pueden ser una inversión para el futuro.