La version 2.2 de Sonar vient de sortir. Parmi une soixantaine d'améliorations et corrections de bogues se trouvent également trois fonctionnalités majeures qui viennent enrichir l'outil ainsi que augmenter les possibilités de l'étendre par des greffons :
- Filtres : les utilisateurs peuvent définir des filtres et créer des onglets afin d'obtenir une vue sur un sujet particulier. Par exemple : tous les projets, les tests unitaires dont l'exécution est la plus longue, les classes avec une couvertures par les tests unitaires < 50% et une complexité moyenne par méthode > 10...
- Favoris : il est maintenant possible de marquer une ressource (projet, module, package, fichier) comme étant une ressource favorite ce qui permet de la retrouver par la suite dans un onglet dédié aux favoris.
- Le chargeur de classe des greffons : chaque greffon est maintenant exécuté dans son propre classloader. Le principal avantage en est que les greffons peuvent maintenant déclarer leurs propres dépendances au lieu d'être limités aux bibliothèques fournies par Sonar.
Aller plus loin
- Sonar (13 clics)
- Démonstration de l'application (6 clics)
- Les copies d'écran de Sonar 2.2 (7 clics)
- Notes de publication de la version 2.2 (4 clics)
- Sortie de la version 2.1 de Sonar (7 clics)
# C'est triste
Posté par groumf . Évalué à 3.
Je penses pas qu'il existe un équivalent aussi sexy pour python, re-sniff
[^] # Re: C'est triste
Posté par djano . Évalué à 3.
Yapluka!
[^] # Re: C'est triste
Posté par roduit (site web personnel) . Évalué à 2.
Il t'affiche pour chaque modules le pourcentage de code couvert, et te liste les lignes qui ne le sont pas.
Bon, ce n'est pas un truc graphique à cliquer, mais il est simple à utiliser.
# Avoir l'outil c'est bien, l'utiliser utilement c'est mieux
Posté par jcs (site web personnel) . Évalué à 5.
Par exemple j'ai écrit une règle pour le maven-enforcer-plugin qui bloque toute release d'un projet si les règles de coding style ne sont pas suffisamment respectées (< 95%). On peut imaginer ça également sur la couverture de code des tests. Rien d'extraordinaire certes mais c'est un début.
Et vous comment utilisez vous Sonar pour améliorer la qualité code ? Je serais très intéressé pour échanger sur ce sujet : quelles métriques/données utilisez vous ? Quelles procédures et quelles (bonnes) pratiques avez vous mis en oeuvre sur vos projets ?
[^] # Re: Avoir l'outil c'est bien, l'utiliser utilement c'est mieux
Posté par martopioche (site web personnel) . Évalué à 4.
Après, comme tu le dis, il s'agit de savoir comment interpréter les différentes métriques. Chez mes clients dernièrement, la grande mode est "la couverture du code". Arf... l'objectif est respecté, le manager aura sa prime, mais... 90 % des tests sont foireux et ne testent rien de pertinent (mais couvrent beaucoup).
Donc tu a raison dans ton titre : il faut savoir ce qu'est Sonar (un dashboard de métriques et surtout de leur évolution) et c'est la seule utilisation réellement pertinente de cet outil.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.