CRAP : une métrique pour mesurer la complexité des codes mal testés
En bref
- Google propose CRAP (Change Risk Anti-Pattern), une formule combinant la complexité cyclomatique et la couverture de tests pour identifier le code à risque.
- La formule : complexité² × (1 - couverture/100)³ + complexité, pondérée par le coût de modification.
- L'outil a eu des versions pour Eclipse et Java, mais le projet n'est pas maintenu depuis des années.
- Le débat HN soulève une objection centrale : utiliser la couverture de tests comme indicateur principal présume que tout code non testé est mal écrit, ignorant les pratiques légitime de test sélectif ou de code "correct par construction".
Ce que dit la source
Alberto Savoia et l'équipe de Google Testing proposent une métrique automatisée pour détecter le code « crappy » : le CRAP score. L'hypothèse est qu'un code complexe et peu testé présente un risque élevé de bug lors des modifications. La formule pondère la complexité cyclomatique par le déficit de couverture de tests, l'idée sous-jacente étant que les développeurs évitent naturellement d'écrire des tests pour du code complexe et mal conçu.
- La formule CRAP1 est : comp(m)² × (1 – cov(m)/100)³ + comp(m), où comp = complexité cyclomatique et cov = couverture de tests en pourcentage.
- CRAP4J pour Java visait l'intégration Eclipse et Jenkins, mais les dépôts de mise à jour ont cessé d'être maintenus depuis le blog de 2011.
- L'outil suppose que la couverture de tests est l'indicateur fiable de qualité, or de nombreux développeurs pratiquent le test sélectif ou le « correct from construction » sans mesurer la couverture.
- L'adoption a été pénalisée par des problèmes techniques (dépôt cassé, incompatibilité Java 7) et l'absence de maintenance.
Dans les commentaires
Débat partagé sur le bien-fondé de la métrique elle-même plutôt que sur son exécution, avec scepticisme marqué envers les métriques comme proxy de qualité logicielle.
- Plusieurs commentateurs contestent l'axiome fondateur : la couverture de tests ne mesure pas la qualité du code. Un code simple n'a pas besoin d'être exhaustivement testé, et l'absence de tests ne signale pas une mauvaise conception.
- Argument récurrent selon lequel les métriques (cyclomatique, CRAP, coverage) deviennent contre-productives une fois utilisées comme cible d'optimisation (« Goodhart's Law »). Les développeurs ajustent le score plutôt que d'améliorer le code.
- Un commentateur note que l'industrie oscille entre extrêmes : d'abord les fonctions doivent être courtes (Uncle Bob), maintenant les fonctions longues sont à la mode. Les métriques servent peu de guide stable.
- Observation que les outils AI modernes génèrent massivement de tests tautologiques et silly, rendant la couverture un paramètre bruyant et peut-être inutile pour détecter le vrai risque.
- La blague implicite du titre (CRAP) ne passerait plus en communication d'entreprise moderne, signe d'un changement de ton corporatif en quinze ans.
Notre lecture
CRAP demeure une tentative ingénieuse de capturer le couplage entre complexité et testabilité. Mais le débat HN révèle un piège classique : présumer que la couverture de tests reflète la qualité du code ignore les pratiques légitimes de test sélectif et la variété des domaines métier. La métrique a stagné après 2011 (pas de maintenance, incompatibilités) et n'a jamais décollé au-delà de niches Java/Eclipse. Pour un DSI, ce n'est pas un outil clé-en-main : intéressant à comprendre comme cas d'école sur les pièges des métriques logicielles, mais sans pertinence opérationnelle immédiate. Si vous imposez CRAP en CI, attendez-vous à des optimisations gaming plutôt qu'à une meilleure qualité réelle.