Contexte et principe du métrique CRAP

Le blog Google Testing a présenté en 2011 le concept CRAP (Change Risk Analysis and Predictions) comme indicateur combinant couverture de tests et complexité cyclomatique. L’objectif affiché est de repérer les parties du code où la couverture est faible alors que la complexité reste élevée, ce qui augmente le risque d’erreurs lors de modifications futures.

Architecture du plugin CRAP4J

CRAP4J se déploie sous forme d’un eclipse plugin et d’un artefact .jar (exemple : org.crap4j.eclipse.feature_1.1.6.jar). Le plugin analyse les classes Java compilées, extrait la complexité cyclomatique via les byte‑code et croise ces données avec les rapports de couverture générés par des outils comme JaCoCo. Les résultats sont exposés sous forme de métriques affichées dans l’IDE et peuvent être publiés dans les serveurs d’intégration continue (Jenkins/Hudson), comme le souligne un utilisateur qui a intégré CRAP4J à son pipeline CI.

public Value getValue() { return value; }

Ce fragment, cité dans les commentaires, illustre un cas où la couverture est triviale mais la métrique CRAP reste basse, évitant ainsi un faux positif que d’autres outils de couverture auraient pu générer.

Limitations et problèmes d’exploitation

Plusieurs retours d’expérience indiquent des difficultés concrètes : les liens de téléchargement du plugin sont souvent morts (« Repository not found », « gateway timeout »), rendant l’installation impossible sans recours à des archives tierces. De plus, la version 1.1.6 ne supporte pas Java 7, ce qui bloque les projets modernes et nécessite des ajustements manuels (voir le blog externe mentionné pour un contournement). Enfin, la dépendance à la couverture de tests implique que toute insuffisance de cette dernière fausse la métrique : les outils de couverture classiques produisent de nombreux faux positifs, alors que CRAP4J ne signale que les méthodes réellement à risque, mais uniquement si la couverture est correctement mesurée.

Perspectives d’évolution

Le modèle CRAP reste pertinent pour la gestion du risque technique, mais son adoption est freinée par l’obsolescence du plugin et l’absence de mise à jour officielle. Une ré‑implémentation compatible avec les standards actuels (Java 11+, Gradle/Maven, rapports Cobertura ou JaCoCo) permettrait de restaurer son utilité dans les chaînes DevOps modernes.