Dans un contexte de développement logiciel en entreprise, les initiatives pour maintenir, améliorer et mesurer la qualité des livrables, sont habituelles et bienvenues, parfois sensées et judicieuses. Néanmoins, elles peuvent ne rien résoudre en adressant le mauvais problème, car les outils de mesure sont incompris ou inappropriés, voire utilisés à des fins détournées pour se construire une meilleure image, en toute conscience ou par ignorance.
Cet article traite de l’utilisation abusive du pourcentage de couverture calculée lors de l’exécution de tests unitaires sur le code productif d’un produit logiciel, comme indicateur de performance et indice d’acceptance, afin de sensibiliser les équipes de développement au maintien de la qualité et à la productivité.
« Pour améliorer la qualité du code logiciel, nous allons demander aux développeurs de couvrir systématiquement leur code productif par 82.5 % de test unitaires. »
La mise en place d’une telle mesure doit être vivement mise en question afin de relever l’utilisation inappropriée d’une métrique comme indicateur de performance pour traiter de manière simpliste une problématique profonde.
Un autre exemple de métrique mal utilisée est le nombre de lignes de code produites ou le nombre de « commit » exécutés par un développeur comme indicateur de sa performance journalière.
En conséquence il est important de définir correctement la notion de qualité d’un logiciel, l’utilité d’écrire des tests unitaires en amont, ainsi que la productivité d’une équipe de développement logicielle en activité.
Dans la pensée complexe, une équipe de développement est considérée comme un système adaptatif complexe. En imposant une contrainte extrinsèque à une équipe, cette dernière s’adaptera, et jouera avec l’indicateur de performance afin de pouvoir se concentrer sur la livraison de valeur. Effectivement il est fréquent de voir les tests d’acceptance ou les tests d’intégration remplacer les tests unitaires puisque le pourcentage de couverture minimal requis est atteint; dans ce cas le feedback rapide offert par les tests unitaires est bafoué et les régressions dues aux micro-fissures prendront plus de temps à émerger. Un autre exemple est celui de concentrer l’effort à tester des parties du code productif sans complexité et sans risque réel de régression, simplement pour augmenter le pourcentage de couverture; en conséquence dès que le pourcentage de couverture minimal requis est atteint, il est fréquent de voir l’effort relâché au détriment des parties les plus importantes et qui ont le plus d’impact sur les fonctionnalités livrées.
La couverture de code n’est qu’une petite partie du vrai problème à résoudre.
En utilisant la méthode de résolution des « 5-pourquoi » pour déterminer la cause principale du problème rencontré, on peut conclure que la qualité d’un logiciel ne se mesure pas par le nombre de lignes de code couvertes à l’exécution des tests, mais par la qualité des tests eux-mêmes. Un test qui couvre une partie de code est inutile s’il ne déclenche aucune alerte en cas de régression.
Les mindsets #Craftsmanship et #XP promeuvent le Test-Driven Development (TDD) pour la rédaction du code et découragent l’écriture d’une ligne de code en l’absence d’un test unitaire en échec.
Le TDD est bien plus que du test.
Le TDD permet de documenter le code tout en spécifiant le comportement attendu. Il permet de développer par petits incréments en toute sécurité et avec un feedback rapide. Une capacité sous-estimée du TDD est la contribution au design logiciel pendant la rédaction. Les artisans logiciels qui utilisent le TDD n’ont pas besoin d’utiliser une contrainte de couverture pour produire un code de qualité, car la couverture est naturellement très élevée. En conséquence toute ligne de code non-couverte par les tests est vraisemblablement du code mort.
Si vous voulez en savoir plus sur le TDD, je vous recommande la nouvelle vidéo de CleanCoders, en particulier la dernière de la série entre Oncle Bob (Robert C. Martin) et Sandro Mancuso.
https://cleancoders.com/videos/comparativeDesign
Sinon, venez rejoindre une communauté de Software Craftsmanship près de chez vous, où vous rencontrerez d’autres experts.
