|
|
La couverture du code de tests unitaires sous .NET, avec NCover par Laurent Desmons | |
|
|
|
Vous avez peut-être déjà entendu parler de "code coverage". Cet article propose de vous accompagner dans les détails de ce sujet passionnant, qui forme une des briques du développement logiciel moderne. Je présenterai tout d'abord les principes généraux du code coverage, avant de me concentrer sur la couverture de code des tests unitaires, dont l'étude détaillée représente l'objectif de cet article.
J'appliquerai ensuite ces principes à l'outil simple, mais suffisant, et gratuit appelé NCover. Nous verrons qu'il collabore efficacement avec les outils de tests unitaires comme NUnit. Puis je me pencherai sur l'intégration de cet outil dans un processus de build piloté par NAnt et CruiseControl .NET.
Le plan détaillé de cet article est ainsi le suivant:
De nos jours, il est difficile de remettre en cause l'intérêt des tests unitaires, tant ils ont prouvé leur efficacité pour assurer la qualité et la robustesse du code. Cela étant, comment mesurer cette efficacité ? Admettons que 100% des tests unitaires passent. Très bien, mais sur quel code exactement ? Qu'est-ce qui prouve que l'ensemble du code écrit fonctionne à 100% ? Est-on bien sûr d'avoir tout testé ? Est-ce qu'il reste du code qui n'a pas encore été testé ? Si oui, est-ce que ce code non testé est critique pour l'application ?
Le terme "code coverage" (qui signifie "couverture de code") tente d'apporter une réponse immédiate à ces questions. Pour résumer, il permet de savoir à quel point les tests unitaires couvrent le code écrit, et ce de manière objective : le degré de couverture de code est en effet mesuré par des indicateurs statistiques, et les portions de code qui ne font pas l'objet de tests unitaires sont mises clairement en évidence.
L'objectif des tests unitaires est de vérifier que le code exécute ce qu'on attend de lui; l'objectif du code coverage est de s'assurer que les tests unitaires couvrent bien l'ensemble du code écrit. Il ne faut donc pas confondre avec une mesure de qualité du produit final : ici on ne s'intéresse qu'à la mesure de la qualité des tests unitaires. Cependant, l'intérêt est indéniable, pour qui ose se mettre un instant dans la peau d'un client, lequel ne peut que se satisfaire d'avoir pour son projet un taux de 100% de tests unitaires réussis tout en étant assuré que ce taux est évalué sur près de l'intégralité du code.
L'analyse de la couverture du code apporte donc une vision quantitative inestimable sur la qualité du code écrit. Il se fonde principalement sur des évaluations appliquées sur l'ensemble du code et du code de tests et qui s'expriment grosso-modo sous la forme d'une formule aboutissant à un pourcentage :
% code coverage = quantité de code testé / quantité de code écrit
Ce pourcentage peut être appliqué par classe, par méthode, par assembly, par projet... Le code coverage permet de quantifier objectivement la qualité des tests unitaires en apportant un moyen visuel immédiat de juger de leur pertinence et de leur stabilité. Il est nécessaire cependant de cibler prioritairement le code à haut risque ou à forte valeur ajoutée car un objectif idéal de 100% de code coverage est illusoire, voire complètement déplacé par rapport aux objectifs réels qu'on attend d'un tel outil. En effet, il s'agit de ne pas perdre trop de temps à implémenter du code de tests pour à tout prix atteindre les objectifs fixés en terme de code coverage, mais bien à développer le code à tester (cette remarque vaut d'ailleurs également pour la technique du Test-Driven Development). On cherche à s'assurer que le code applicatif répond bien aux fonctions à implémenter, et y répond encore à chaque itération dans le cycle de développement du logiciel.
Il est sans doute très subjectif de proposer des chiffres, tant ils dépendent des projets et du degré d'intégration des tests unitaires au sein même des équipes de développement. On peut quand même se hasarder à dire que des objectifs raisonnables semblent se situer aux alentours de 80-90% de code coverage pour la moyenne de l'ensemble des développements. Cela représente déjà un objectif ambitieux pour les équipes de développement qui n'ont pas une grande expérience en rédaction de tests unitaires.
Il faut simplement retenir que l'important, finalement, c'est d'obtenir 100% de tests unitaires réussis. Obtenir un bon pourcentage de code coverage permet ensuite de s'assurer objectivement que ces tests unitaires sont probants pour l'ensemble du code écrit. Et il s'agit là d'un atout considérable, notamment quand on l'associe au refactoring de code (sur lequel je ne m'étendrai pas, car cela fait l'objet d'autres articles par ailleurs). Le code coverage trouve d'ailleurs toute sa justification quand le code comporte beaucoup de ramifications et de chemins d'exécution différents possibles, car c'est précisément dans ces cas de figure que des tests unitaires exhaustifs et suffisants sont les plus difficiles à mettre en place.
Même s'il ne faut évidemment pas fonder directement la qualité du code sur ce simple critère objectif, mon opinion est qu'il est définitivement indispensable de mettre en oeuvre le code coverage si on utilise déjà les tests unitaires.
Je vois au moins trois raisons à cela :
on ne peut pas fondamentalement parler de tests unitaires sans s'assurer de leur pertinence
la mise en oeuvre du code coverage sous .NET est d'une facilité et d'une simplicité déconcertantes
il est vraiment difficile d'ignorer les nombreux avantages que le code coverage procure
Examinons le dernier point un peu plus en détail.
On parle souvent de "white box testing" en opposition à "black box testing", pour mettre l'accent sur le fait que le code est analysé en interne, au niveau de l'implémentation des classes, et pas seulement sur les interfaces exposées par ces classes. Adopter le code coverage, c'est donc améliorer radicalement la productivité des tests unitaires, car c'est au niveau de la ligne de code qu'il fonde ses statistiques.
En pratique, le code coverage permet ainsi de :
Tout un programme, n'est-ce-pas ? Cela n'est pas sans rappeler les objectifs finaux du développement piloté par les tests, en ce sens que l'accent est mis sur le fait que le code de tests est au moins aussi important que le code testé.
Dans cette optique, l'objectif principal de cet article est de montrer comment profiter de tous ces immenses avantages en utilisant des outils de code coverage :
simples et rapides à mettre en oeuvre
qui n'impliquent pratiquement aucune perte de temps
qui s'intègrent naturellement dans les éventuels environnements de développement existants
Encore un peu de patience toutefois car, avant d'en arriver là, j'aimerais faire encore un petit peu de théorie en présentant rapidement les principales méthodes d'analyse de couverture de code.
Il existe plus d'une façon de mesurer la couverture de code. Je vais tenter de présenter les principales mesures une par une, sachant qu'il en existe beaucoup d'autres et que ce chapitre n'a pas pour ambition d'être un cours sur le sujet.
Ceci n'est qu'un rapide tour d'horizon : le lecteur intéressé pourra toujours approfondir le sujet en lisant par exemple l'article suivant. Nous allons maintenant entrer dans le vif du sujet et nous concentrer sur la couverture du code des tests unitaires.
Le chapitre précédent doit servir de sonnette d'alarme : le code coverage est un exercice difficile à mettre en oeuvre, voire périlleux si on veut vraiment en faire un outil analytique précis. L'analyse peut même dans certains cas extrêmes devenir plus complexe que le code à analyser! Il ne faut pas perdre de vue l'objectif : rédiger des tests unitaires les plus exhaustifs et les plus efficaces possibles. Le code coverage est un indicateur minimum à prendre en compte mais il ne résoud pas tout, bien au contraire : il doit dans le cadre de notre étude se limiter à valider l'étendue des tests unitaires.
Il s'agit d'aller à l'essentiel, donc de faire preuve d'agilité et de cibler uniquement l'analyse à partir du Statement Coverage basé sur l'exécution des tests unitaires. Le fait d'identifier les lignes de code couvertes par les tests unitaires et, surtout, celles qui ne le sont pas suffira à la majorité de nos besoins.
Ainsi, on partira avec les principes suivants:
par définition, du code est dit "couvert" s'il est parcouru au moins une fois par des tests unitaires, c'est-à-dire si une partie des tests unitaires exécute au moins une fois les lignes de code correspondantes
tout le reste du code (donc, non parcouru par les tests unitaires) est considéré comme "non couvert"
l'analyse de la couverture de code consiste à surveiller l'exécution des tests unitaires et à maintenir des compteurs de passage sur chaque ligne de code, pour en déduire des statistiques sur l'ensemble du code à couvrir
On peut donc parler "d'analyse de code pilotée par les tests unitaires", car c'est bien le code des tests unitaires qui doit parcourir l'ensemble du code qu'on veut définir comme "couvert". Ensuite, une fois habitué à cette technique, il sera toujours temps d'affiner un le processus si le besoin s'en fait sentir. Mieux vaut une analyse simple qui donne de bons résultats et qu'on maîtrise bien, qu'une analyse plus complexe et plus fouillée mais qui n'apporte rien de plus qu'1 ou 2% de coverage supplémentaire.
L'expérience montre que cela suffit, et que ce n'est déjà pas si évident à mettre en place en tant que méthode de travail. Nous avons déjà mis le doigt sur des problèmes potentiels de logique dans le chapitre précédent. En effet, il faut faire bien attention à la simplicité apparente de cette démarche, car si le code coverage est destiné à couvrir le code qui existe, il est bien entendu incapable de couvrir celui qui devrait exister. Prenons un exemple tout simple mais explicite avec le bout de code suivant (tiré du document How to misuse code coverage dont je ne peux que conseiller la lecture):
Le code coverage ici peut indiquer au développeur que le code après le "if" n'est jamais exécuté, s'il n'existe encore aucun test unitaire qui permet de faire en sorte que la variable "status" soit positionnée à ErrorCode.Fatal. Le code coverage permet donc ici de détecter le fait qu'il faut ajouter un test unitaire supplémentaire pour atteindre les 100% de couverture de code. On obtient donc après ajout du test des chiffres de 100% de tests réussis sur 100% de code couvert. Merveilleux. Mais le code coverage est incapable d'indiquer au développeur qu'en fait la variable "status" peut prendre non pas 2, mais 3 valeurs possibles et qu'en conséquence le code aurait dû être écrit de la façon suivante :
Ce genre d'erreurs arrive bien plus souvent qu'on ne croit. Moralité : avoir 100% de tests unitaires réussis et 100% de code coverage correspondants ne signifie donc pas que le code est exempt de défauts. Dans ce contexte, l'objectif de 100% de code coverage est ainsi parfaitement inutile : il ne s'agit pas de tester chaque ligne de code mais plutôt de s'assurer que l'ensemble du code critique à exécuter est bien couvert par les tests unitaires.
Mais tout cela, pour l'instant, est bien théorique. Dans les faits :
est-il si simple de mettre en oeuvre le code coverage ? OUI
doit-on modifier le code existant pour permettre son analyse ? NON
peut-on disposer d'indicateurs visuels immédiats pour évaluer le code coverage ? OUI
peut-on accéder directement au code non couvert afin de pouvoir lui associer des tests unitaires ? OUI
peut-on automatiser l'analyse de code en parallèle avec les tests unitaires déjà en place ? OUI
Toutes ces questions trouvent leur réponse grâce à l'existence d'un outil simple, puissant et gratuit, créé par Peter Waldschmidt pour la communauté GotDotnet : NCover, et son intégration naturelle dans un processus de build piloté par NAnt.
NCover est un analyseur de code (gratuit) qui analyse l'exécution du code en runtime et enregistre des statistiques sur les lignes de code exécutées. Il montre chaque séquence d'exécution dans l'application ainsi que le nombre de fois où chaque séquence a été exécutée.
Puisque NCover se base sur des séquences générées par le compilateur et stockées dans les fichiers d'informations *.PDB, il est nécessaire que l'analyse porte sur du code généré en debug (donc, typiquement, pas sur du code en production).
NCover travaille de façon transparente : il n'y a aucune modification de code à intégrer. NCover utilise l'API de profiling du Framework .NET afin d'analyser le code. Il ne nécessite pas d'étape de compilation particulière.
Le fonctionnement suit les principes suivants:
NCover produit en fait 3 rapports dans le répertoire d'exécution, à la fin de son analyse:
Il faut bien comprendre que NCover analyse le code qui s'exécute : si on veut analyser la couverture du code par les tests unitaires, alors c'est bien le code exécuté par les tests unitaires qu'il faudra instrumenter. Pour l'instant nous allons simplement installer NCover et nous inspirer de l'exemple concret donné sur GotDotNet pour voir NCover en action et comprendre comment cet outil peut nous assister simplement dans notre analyse du code coverage.
Pour mettre en oeuvre NCover il suffit de télécharger et d'installer la dernière version de NCover, sans oublier ensuite d'ajouter le chemin d'installation dans la variable d'environnement PATH (noter bien que NCover n'est compatible qu'avec la version 1.1.4322 du framework et, donc, Visual Studio 2003).
Pour l'exemple, créer ensuite une nouvelle application console en C# appelée NCoverApp qui contient le code suivant :
Builder le projet en debug. Cette application contient deux fonctions MethodeA() et MethodeB(). Il apparaît clairement que MethodeA() est la seule fonction appelée par Main() et que MethodeB() ne sera donc jamais exécutée ("dead code"). On doit donc s'attendre à avoir :
100% de code coverage pour Main()
100% de code coverage pour MethodeA()
0% de code coverage pour MethodeB(), ou 100 % de code non couvert si on préfère
donc, 2/3 de code couvert au total, et 1/3 de code non couvert
Voyons donc comment NCover nous présente ce résultat. La version console de NCover se lance en ligne de commande sous .NET avec la syntaxe suivante :
NCover.Console / c <command line> [/a <assembly list>]
avec :
D'autres commutateurs existent, que vous pouvez découvrir en tapant simplement "NCover.Console" comme ligne de commande. Dans notre exemple, la ligne de commande à lancer depuis le répertoire bin\debug de NConsoleApp est donc la suivante :
NCover.Console /c NCoverApp.exe /a NCoverApp
*** ATTENTION : les noms des assembly sont case-sensitive dans cette ligne de commande !! Si la casse n'est pas respectée alors NCover produit un rapport vide... ***
Voici ce que donne l'exécution de NCover :
Figure 1 : le résultat de l'exécution de NCover
NCover produit alors ses 3 fichiers de résultat dans le répertoire bin\debug. Remarquez que le fichier XSL est systématiquement copié depuis le répertoire d'installation de NCover jusque dans le répertoire d'exécution. Ouvrez ensuite le fichier Coverage.xml avec le fichier XSL par défaut dans Internet Explorer (par exemple) afin de vérifier que NCover maintient un compteur de passage par ligne de code, et que donc les deux compteurs de MethodeB() sont bien à 0 alors que ceux de MethodeA() sont à 1:
Figure 2 : le rapport NCover par défaut
Vous noterez tout de suite que ce rapport par défaut n'est pas très clair ni immédiat : il nous manque notamment nos fameuses statistiques ! Heureusement, ces informations se trouvent bien dans le fichier XML et il suffit donc de changer de fichier XSL pour obtenir un rapport plus clair. Je vous conseille fortement de télécharger le fichier XSL créé par Yves Lorphelin. Il suffit de le copier dans le répertoire d'installation de NCover à la place du fichier coverage.xsl livré par défaut avec NCover puis de relancer l'analyse pour obtenir un rapport bien plus explicite. On peut afficher ou masquer les statistiques ainsi que les détails de chaque compteur de passage.
Voici donc ce que cela donne maintenant avec ce nouveau fichier XSL. Ce qui est couvert est en vert, ce qui n'est pas couvert est en rouge, et 100% de rouge indique donc que RIEN n'est couvert du tout, ce qui correspond bien à notre "code mort" qu'on pourra tranquillement enlever par la suite :
Figure 3 : le rapport NCover amélioré
Remarque : pour être à peu près complet il existe aussi un add-in qui permet de visualiser le code coverage de manière graphique (tree map) dans Reflector .NET, mais il ne semble pas donner des résultats fiables...
NCover permet donc d'analyser simplement le statement code coverage et de présenter les résultats de façon explicite et donc directement exploitable. Il nous reste maintenant à comprendre comment NCover collabore avec NUnit pour analyser la couverture de code des tests unitaires.
Il existe différents outils pour mettre en oeuvre les tests unitaires. Le plus connu et le plus utilisé est sans doute NUnit, et c'est celui que nous utiliserons pour cet article, d'autant plus que NCover a été conçu pour fonctionner très bien avec. Je conseille vivement au le lecteur qui ne connait pas bien ces outils (et d'autres...) d'approfondir le sujet avant de poursuivre, en se référant par exemple à cet article.
Le principe est tout simple : plutôt que d'analyser directement le code applicatif, NCover analyse le code exécuté par NUnit pendant qu'il parcourt l'ensemble des tests unitaires liés au code applicatif. Donc NUnit sert de pilote d'exécution de code pour NCover. Concrètement cela signifie qu'il faut simplement lancer NCover en intégrant NUnit dans la ligne de commande.
Il faut tout d'abord bien sûr implémenter les tests unitaires pour permettre à NCover d'analyser leur couverture. Je m'empresse d'ajouter que la mise en oeuvre est exactement la même pour les aficionados de MbUnit, ainsi que pour les tests des WinForms sur lesquelles on clique un peu partout, ou pour les tests des WebForms (pour lesquelles il faut un peu bidouiller quand même, voir la FAQ de NCover sur GotDotNet), ou pour les tests automatiques sur l'ensemble des méthodes de toutes les classes, etc...
Nous allons créer un nouvel exemple pour démontrer tout ça. Créer une nouvelle Class Library en C# appelée NCoverDemoLib qui contient deux classes : une appelée NCoverDemo qui va représenter le code applicatif à tester et une autre appelée NCoverDemoTest qui va tester les méthodes de la classe NCoverDemo:
Il nous faut maintenant une méthode de la classe NCoverDemo à tester. Créons donc une méthode appelée MethodeATester() qui renvoie simplement la somme de deux entiers, sauf si le premier vaut 0 auquel cas elle renvoie 0, ou si les deux sont égaux auquel cas elle renvoie 1. Cette méthode, très simple, est cependant déjà assez emberlificotée pour nous permettre de tester simplement plusieurs cas de Statement Coverage (j'ai mis le numéro de ligne en commentaires pour la suite):
NUnit va exécuter le code de toutes les méthodes marquées de l'attribut [Test] de toutes les classes marquées de l'attribut [TestFixture], en l'occurence ici la classe NCoverDemoTest. Ajoutons donc une méthode appelée MethodeDeTest() qui va simplement appeler MethodeATester() avec différentes valeurs de paramètres. Le but est d'arriver à 100% de tests unitaires réussis, et si possible 100% de code coverage.
Nous allons commencer volontairement par ne pas tout tester, et je dois même insister ici en disant que même volontairement, il est très facile d'oublier des tests. Commençons donc par tester MethodeATester() en lui fournissant uniquement des paramètres "aléatoires", et en oubliant les cas particuliers :
Pour analyser le code des tests ci-dessus la ligne de commande nécessaire devient ensuite (en supposant que le chemin d'installation de NUnit a bien été ajouté dans la variable d'environnement PATH):
NCover.Console /c NUnit-Console NCoverDemoLib.dll /a NCoverDemoLib
Le résultat de cette analyse est éloquent :
Figure 4 : analyse d'un code non couvert
On se rend tout de suite compte que :
1/3 environ du code de MethodeATester() n'a pas été testé
ce code non testé se situe à la ligne 22 qui n'a pas été visitée (ce qui correspond au cas x=0) et à la ligne 24 qui n'a pas été visitée (ce qui correspond au cas x=y)
Conclusion : il faut donc compléter les tests unitaires en tenant compte des deux cas x=0 et x=y qui manquent effectivement à l'appel :
Après nouvelle analyse par NCover, miracle ! on a ensuite droit à un superbe écran de résultat 100% vert :
Figure 5 : analyse d'un code couvert à 100%
NCover a donc fait en sorte de nous indiquer des tests supplémentaires à intégrer dans NUnit, ce qui ne peut qu'être profitable. Avec la même méthode, on peut être amené à enlever des tests, résoudre des tests contradictoires, etc... dès que le code coverage indique quelquechose en rouge, il faut en connaître la raison (mais pas non plus en être obnubilé). L'analyse doit toujours se faire dans cet ordre car en cas d'échecs des tests unitaires, NUnit arrête l'évaluation de la fonction de test en cours (avant de passer à la suivante), ce qui fait descendre encore plus le taux de code coverage.
J'aimerais faire remarquer au passage que cet exemple, bien que trivial, réclame déjà de l'attention et une certaine dose de travail. Il démontre aussi que le code coverage est un outil d'aide qui peut s'avérer précieux pour accompagner le développement piloté par les tests.
Je ne peux que vous encourager à approfondir la pratique de NCover. En attendant, si la ligne de commande vous rebute, sachez qu'il existe une interface graphique pour NCover appelée NCoverGUI.
NCoverGUI est une application Windows qui permet de :
Pour l'instant cette application ne permet d'analyser que les EXE. Elle est disponible sous la forme d'un fichier ZIP. Après extraction (dans un répertoire distinct de NCover) on dispose alors d'un outil plus pratique que la ligne de commande pour lancer des analyses à la demande :
Figure 6 : NCoverGUI, l'interface graphique pour NCover
Cette interface est plus un gadget qu'un réel utilitaire. Par contre la communauté GotDotNet propose également quelque chose de bien plus intéressant, sous la forme d'un plug-in NCover pour Visual Studio .NET, appelé NCoverViewer.
NCoverViewer est un plug-in pour Visual Studio .NET qui permet de visualiser les résultats de NCover sous la forme d'un arbre facilement navigable, et dans lequel apparaissent les statistiques à chaque niveau de l'arbre. Avantage suprême : on peut également accéder directement aux lignes de code à partir des résultats de NCover.
Il suffit de télécharger la dernière version de NCoverViewer puis de l'installer. Ensuite le plug-in apparait dans Visual Studio .NET :
Figure 7 : le plug-in NCoverViewer dans Visual Studio .NET
On peut alors lancer directement l'analyse (en spécifiant les assembly à analyser) ou bien charger un fichier coverage.xml existant. Il ne faut pas oublier cependant de bien préciser la même ligne de commande que NCover à exécuter (donc, ne pas oublier le NUnit-Console) sinon il ne se passera rien :
Figure 8 : choix des assembly pour NCoverViewer
Le résultat s'affiche dans une belle petite fenêtre, et on peut naviguer aisément parmi les résultats :
Figure 9 : NCoverViewer en action
J'estime que ce plug-in est une petite merveille, tout simplement indispensable pour travailler avec NCover. Cela dit, encore plus indispensable est la faculté pour NCover de pouvoir s'intégrer sans mal dans un outil de build comme NAnt, afin de disposer automatiquement d'une analyse de code coverage à chaque fois que des tests unitaires doivent être exécutés sur un serveur de build.
Encore une fois, le lecteur peu habitué à un outil de build comme NAnt ou aux notions d'intégration continue (avec des outils comme CruiseControl .NET par exemple) a tout intérêt à approfondir ce sujet avant d'aller plus loin dans cet article (et ici aussi on pourra se référer à cet article).
Du moment qu'on dispose d'un fichier de configuration pour NAnt, il y a fort à parier qu'on dispose déjà d'une batterie de tests unitaires automatiques. Sinon, il est grand temps de les intégrer ! Il est ensuite extrèmement simple d'intégrer NCover dans le fichier de configuration de NAnt : il s'agit en effet juste de créer une nouvelle tâche <exec> chargée de lancer NCover comme depuis la ligne de commande (on suppose ici aussi que le PATH a bien été modifié pour y inclure les chemins d'installation de NUnit et NCover, sinon il faut préciser le chemin complet de ces outils dans la tâche <exec>).
Cette tâche devrait être lancée juste après la tâche des tests unitaires. On peut du coup en profiter pour spécifier d'autres commutateurs de la ligne de commande NCover, par exemple /q pour ne plus rien afficher et /o pour spécifier le fichier XML de sortie. On obtient pour notre exemple avec NCoverDemo :
<target name="NCover" description="Code Coverage par NCover">
<exec
program="NCover.Console.exe"
commandline="/q /o bin\debug\coverage.xml /c NUnit-Console ${nant.project.basedir}\bin\debug\NCoverDemoLib.dll"
/>
</target>
Si NAnt est bien configuré alors le résultat d'un build est conforme à nos espérances :
Figure 10 : NAnt, NUnit et NCover
L'étape suivante consiste naturellement à intégrer NCover dans un processus de build complet, comme par exemple CruiseControl .NET.
Puisque c'est la tâche <exec> que nous venons d'intégrer dans NAnt qui effectue tout le travail, l'intégration avec CruiseControl .NET consiste essentiellement à pouvoir visualiser facilement les résultats produits par NCover, à partir de l'écran de build de l'interface Web de CruiseControl .NET.
Pour cela il faut suivre deux étapes :
fusionner les fichier de résultat XML avec les fichiers de résultat déjà intégrés (comme par exemple NDoc, FxCop, NUnit...)
faire apparaître ce résultat dans l'interface Web de CruiseControl .NET
Voyons ces étapes dans le détail.
Comme il s'agit d'un fichier XML l'opération est triviale une fois qu'on est familiarisé avec le fichier de configuration de CruiseControl .NET. En l'occurence il s'agit de rajouter le chemin du fichier "coverage.xml" dans la section <mergeFiles> du fichier de config de CruiseControl .NET :
<cruisecontrol>
<project name="NCoverDemoLib">
<publishers>
<xmllogger>
<mergeFiles>
<file>D:\Develodotnet\Projets\Solutions\NCoverDemoLib\bin\debug\coverage.xml</file>
</mergeFiles>
</xmllogger>
</publishers>
</project>
</cruisecontrol>
Il faut disposer d'une version de CruiseControl .NET qui soit au moins la 0.6.1 car elle dispose d'un plug-in implémenté sous la forme d'une page Web nommée "coverage.aspx". Cette page s'intègre dans l'interface Web de CruiseControl .NET et utilise simplement le fichier XSL de NCover pour transformer le fichier XML de résultat de NCover.
Dans l'ordre, il faut :
<CCNet>
<buildPlugins>
<plugin linkText="NCover" linkUrl="Coverage.aspx?log=" />
</buildPlugins>
</CCNet>
<xslFiles>
<file name="xsl\ncover.xsl" />
</xslFiles>
Ensuite on peut accéder aux résultats de NCover directement dans l'interface Web de CruiseControl .NET, comme pour FxCop, ce qui conforte les habitués de CC .NET dans tout le bien qu'ils pensent de cet outil formidable.
Appliquer les principes du code coverage est un exercice difficile. La tâche peut être considérablement simplifiée si on se restreint à l'analyse quantitative des lignes de code couvertes par les tests unitaires. Il s'agit de disposer d'un indicateur visuel rapide visuel de s'assurer de la qualité et de la pertinence des tests unitaires. Comme tout outil de développement, il ne faut pas en abuser ni le considérer comme la réponse à tous les problèmes.
D'autres outils peuvent également être envisagés:
En tant que tel, le code coverage est un excellent moyen d'être plus objectif sur la qualité du code produit, et rien de plus. J'espère vous avoir convaincu que son intégration dans le cycle de développement logiciel est quasiment indispensable si on utilise déjà des tests unitaires, d'autant plus que des outils comme NCover apportent d'immenses avantages immédiats et pratiquement sans surcharge de travail.
Les méthodes d'analyse de code en détail : Code Coverage Analysis
Un document sur la couverture de code : How to misuse code coverage
NCover (GotDotNet) : www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=3122ee1a-46e7-48a5-857e-aad6739ef6b9
Le fichier XSL pour NCover de Yves Lorphelin : weblog.lorphelin.be/PermaLink.aspx?guid=0bb9d00e-26b0-4b6c-8aba-2215b638b6a7
Un de mes articles précédents sur DNG : Mettre en place un environnement de développement .NET
NCoverGUI : http://www.sliver.com/dotnet/NCoverGui/NCoverGui.zip
NCoverViewer : www.gotdotnet.com/community/workspaces/workspace.aspx?ID=03791D39-B33A-4021-81FB-DB5B28CF984F
NUnit :http://www.nunit.org/
NAnt :http://nant.sourceforge.net/
Auteur : Laurent Desmons
Copyright © 2004