Sonar, l’outil qui manquait à l’usine de développement .NET

Sonar (www.sonarsource.org) est un outil de reporting sur la qualité des projets informatique. Bien qu’à l’origine fait pour le Java, la communauté Open Source a permis l’intégration de Sonar avec d’autre langages : cobol, flex, php, c++ et maintenant .NET.

L’objet de cet article est de vous montrer ce que peut apporter Sonar pour un projet informatique et montrer quelle est sa place dans l’univers .NET.

Sonar : des indicateurs de qualité du code

Sonar centralise les rapports d’outils d’analyse de code pour afficher des informations comme la couverture de test, le respect des normes de développements, la complexité, la duplication

Exemple de tableau de bord Sonar pour un projet .NET

Il est important de prendre ces indicateurs pour ce qu’ils sont : des indices permettant de déceler de la dette technique. Il serait dangereux d’utiliser ces métriques dans l’absolu pour contractualiser la qualité attendue d’un projet.

Nous allons voir d’un peu plus près les métriques les plus significatives.

Tests unitaires et couverture

Tests et couverture Sonar .NET

La seule façon de prouver qu’un code fonctionne, c’est de le tester.

Sonar permet de connaitre le nombre de tests unitaires joués, le taux de succès et la couverture de ces tests.

La couverture de tests correspond au pourcentage de lignes de code du projet qui est appelé pendant la phase de test. Attention : ce n’est pas parce qu’une ligne est appelée qu’elle est testée.

Une couverture élevée n’est donc pas une fin en soi. Par contre, une couverture basse est l’indice d’une carence dans les tests, ce qui est un risque pour le projet.

Une couverture élevée alors qu’il y a peu de tests implique que les tests ne sont pas unitaires, ce qui veut dire que le code couvert n’est probablement pas totalement testé.

Enfin, un taux de succès des tests qui n’est pas à 100% sous entend que les développeurs ne font pas attention lors du checkin/commit.

Complexité et cohérence

Complexité et cohérence Sonar .NET

La complexité d’une méthode et la cohérence d’une classe sont des métriques qui permettent de mettre en évidence des problèmes de maintenabilité et de testabilité.

La complexité d’une méthode correspond plus ou moins au nombre de tests qu’il faudra faire pour couvrir tous les cas. Donc plus la méthode est complexe, plus elle sera difficile à maintenir et à tester.

La cohérence d’une classe (ici LCOM4) est un indicateur intéressant qui permet de trouver les classes qui pourraient facilement être découpées. La valeur LCOM4 correspond au nombre de classes qui pourraient résulter de ce découpage.

Règles de qualité du code

Règles de qualité de code Sonar .NET

Il existe des outils d’analyse statique du code (exemples : Findbugs, Pmd en Java, FxCop, Gendarme en .NET) qui permettent de soulever des bugs potentiels ou des problèmes de maintenabilité.

Dans nos projets nous suivons la procédure suivante :

  • Blocker : c’est un bug, on arrête tout et on corrige.
  • Critical : il y a de fortes chances que ce soit un bug : on essaye de corriger rapidement.
  • Major : ça ne sent pas bon, il vaudrait mieux regarder. On essaye de corriger avant la livraison.
  • Minor et info : pensez à regarder si vous êtes curieux. En général, personne n’agit dessus, alors autant les désactiver.

La qualimétrie dans l’univers .NET

Dans l’univers .NET il existe des équivalents des outils permettant d’obtenir les métriques évoquées avant, mais il n’existe pas de solution de reporting  de celles-ci intégrée à l’usine de développement Team Foundation Server.

Team Foundation Server (TFS)

Le reporting TFS repose sur un cube OLAP contenant les données de build, de test et les work items. Il est donc possible de faire des extractions SQL à destination d’Excel, SharePoint ou Crystal Reports.

Néanmoins, ces rapports ne contiennent que des indicateurs de couverture de test, complexité cyclomatique ou de productivité (nombre de ligne produite, de bug résolu …). Les résultats des analyses de règles de qualité de code (FxCop, StyleCop, Gendarme, NDepend) ou de duplication de code (SourceMonitor) ne sont pas injectés dans le cube.

Ainsi, TFS ne permet pas de créer des rapports d’indicateurs qualimétriques provenant d’outils externes sans développement spécifique, d’où l’intérêt de Sonar.

Sonar pour les projet .NET

Le plugin .NET pour Sonar est né dans une DSI où il y avait autant de projets Java que de projets .NET. Il y avait une volonté de centraliser les informations pour avoir une vue globale des niveaux de qualité  des projets de la DSI.

Sonar propose un dashboard global qui répond à ce besoin :

Tableau de bord multi projets - Sonar .NET

Sonar est conçu pour s’intégrer dans une usine de développement logicielle (Hudson/Jenkins ou bien justement TFS). Cette intégration permet une mise à jour des métriques à chaque build !

Chaque mise à jour est sauvegardée et Sonar propose des graphiques montrant l’évolution des métriques dans le temps :

Evolution des métriques dans le temps - Sonar .NET

Pour finir

Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’eau.

Dans notre prochain article, nous vous montrerons comment mettre en place Sonar pour un projet .NET et comment l’intégrer à un build TFS 2010.

Nous remercions l’équipe de développement du module .NET pour le travail impressionnant qu’ils ont accompli.

Mots-clés: , ,

6 commentaires pour “Sonar, l’outil qui manquait à l’usine de développement .NET”

  1. Merci pour cet article !
    Une info en avant première, une nouvelle version intégrant un parseur de code C# développé par SonarSource est en préparation.
    J’ai vu juste une petite coquille, l’image en dessous de « Complexité et cohérence » provient d’un projet Java, il n’y a pas encore le support du LCOM4 en C#.

  2. Merci pour l’article !
    Vous dites « La couverture de tests correspond au pourcentage de lignes de code du projet qui est appelé pendant la phase de test ».

    N’est-ce pas plutôt la définition stricte d’un sous composant du code coverage qu’est « line coverage » ? Car le code coverage semble être une chiffre calculée sur base du line et branch coverage. Cf. les nombreux exemples sur le site de démo Nemo. Bien sur cela dépend encore du plugin de couverture utilisé, dans votre exemple il n’y a pas de branch coverage.

  3. Omar, ca changera surement dans quelques mois mais pour l’instant il n’y a pas de « branch coverage » pour le c# dans sonar.
    A propos de couverture, le développeur qui maintenait PartCover a décidé de tout réécrire pour partir sur de bonnes bases. Le nouveau produit s’appelle OpenCover et une beta est déjà disponible :
    http://scubamunki.blogspot.com/2011/06/opencover-first-beta-release.html
    Ci-dessous un petit tuto :
    http://www.palmmedia.de/Blog/2011/6/21/code-coverage-testing-with-opencover-and-partcover

  4. [...] Sonar, l’outil qui manquait à l’usine de développement .NET By Maxime ARNSTAMM and Simon Lehericey, 22 June 2011 Sonar (www.sonarsource.org) est un outil de reporting sur la qualité des projets informatique. Bien qu’à l’origine fait pour le Java, la communauté Open Source a permis l’intégration de Sonar avec d’autre langages : cobol, flex, php, c++ et maintenant .NET. L’objet de cet article est de vous montrer ce que peut apporter Sonar pour un projet informatique et montrer quelle est sa place dans l’univers .NET. [...]

  5. [...] Comme on l’a montré dans l’article précédent, Sonar est l’outil indispensable pour évaluer la qualité des projets d’une DSI au fil de l’ea…. [...]

  6. Bonjour

    qu’est ce que vous mettez Pour les seuils de l’indicateur LCOM4 ?
    avez vous d ‘autres indicateurs intéressant ?

    Bien Cordialement

    Abdel

Laissez un commentaire