Bon, que je l’avoue tout de suite : je n’aime pas NCover. Je n’aime pas leur façon de planquer leur version gratuite sur leur site, je n’aime pas qu’ils m’aient appâté pendant un an avec un produit gratuit pour me dire ensuite qu’il fallait payer. Je n’aime pas quand NCover passe cinq minutes à exécuter une montagne de tests et me recrache un fichier de log de couverture absolument vide à la fin. Enfin, je n’aime pas leur intégration médiocre à Visual Studio.
Bref, il fallait autre chose, et ça commençait à urger. Il y avait bien PartCover, mais franchement, il n’est pas facile du tout à faire fonctionner, et il a aussi ses bugs. Bref, inutile de dire que je suis content que Visual Studio 2010 embarque la couverture de code. Mais bon, ce n’est pas si simple que ça à faire fonctionner, et je me disais que ça valait peut-être le coup de faire un petit post pour expliquer tout ce qu’il faut mettre en place pour que ça marche…
Version de Visual Studio
Il vous faut une version Premium ou Ultimate pour que ça marche. Ne passez pas comme moi un quart d’heure à vous demander si c’est un bug dans la Pro, c’est normal… Enfin, normal, c’est beaucoup dire : j’aurais un peu de mal à qualifier de “pro” un développeur qui ne calcule par sa couverture de code, mais bon, passons.
Créer un projet de test
Pour quelqu’un qui vient du monde NUnit, ce n’est pas évident, mais dans Visual Studio, un projet de test n’est pas bêtement un projet qui contient des tests. Ca ne suffit pas… Il faut que le projet ait été créé en tant que projet de test dans l’interface.
Et sinon, vous pouvez le faire reconnaitre après coup en ajoutant la ligne suivante dans le fichier.csproj :
<?xml version=”1.0″ encoding=”utf-8″?>
<Project ToolsVersion=”4.0″ DefaultTargets=”Build” xmlns=”http://schemas.microsoft.com/developer/msbuild/2003“>
<PropertyGroup>
<Configuration Condition=” ‘$(Configuration)’ == ” “>Debug</Configuration>
<Platform Condition=” ‘$(Platform)’ == ” “>AnyCPU</Platform>
<ProductVersion>
</ProductVersion>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>8099f91a-f07e-4450-9506-a46f5d41e627</ProjectGuid>
<OutputType>Library</OutputType>
<AppDesignerFolder>Properties</AppDesignerFolder>
<RootNamespace>TestProject1</RootNamespace>
<AssemblyName>TestProject1</AssemblyName>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<FileAlignment>512</FileAlignment>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
</PropertyGroup>
Par contre, il vous manquera alors le répertoire Solution Items avec les paramètres nécessaires pour les tests, mais là encore, vous pouvez vous débrouiller pour les rajouter après coup, en utilisant la commande “Ajouter un nouvel élément”, et en sélectionnant la bonne entrée comme ci-dessous :
Activer la couverture de code dans les paramètres de test
Vous pouvez alors voir dans le menu les paramètres de test, et choisir le second mode, qui est là pour prendre en charge toute l’instrumentation additionnelle.
En sélectionnant le menu juste en dessous, nommé “Modifier les paramètres de test”, et en entrant dans la section correspondant au mode choisi plus haut, vous allez pouvoir mettre à jour finement ce qui doit être instrumenté dans ce mode, et en l’occurrence activer l’enregistrement de la couverture de code, dans la catégorie “Données et diagnostics” :
Il faudra ensuite cliquer sur Configurer ou double-cliquer sur la ligne pour donner les assemblages qui doivent être traités. Pas très très intuitif, surtout qu’on ne voit pas bien que Configurer est un menu. Enfin, on était peut-être un peu fatigués, mais ni mon collègue ni moi n’avons fait tilt, et surtout, par défaut, il n’y a rien de sélectionné.
Je trouve ça un peu dommage : ça serait bien que Visual Studio mette un avertissement “Vous avez activé la couverture de code, mais aucun projet n’est sélectionné”. Ou au moins qu’il le dise lorsqu’on rejoue les tests. Pour l’instant, on se retrouve juste avec un message expliquant qu’il n’y a pas de données de couverture de code.
Bien choisir les projets
Attention, ce ne sont pas les projets de tests que vous devez choisir dans cette interface de gestion, mais bien les projets à instrumenter.
Et autre détail : vous ne verrez pas les projets qui ne sont pas compilés.
Resharper, lecteur réseau, etc.
Si vous utilisez Resharper, il faudra le désactiver, ou en tout cas ne pas lancer les tests par les commandes qu’ils proposent, car elles ne sont pas compatibles avec la couverture de code.
Autre souci potentiel : Visual Studio acceptera de lancer les tests, mais le fichier de couverture ne sera pas écrit si votre projet se trouve sur un lecteur réseau. Mettez donc votre workspace en local. De toute façon, c’est une bonne pratique, ne serait-ce que pour les performances d’accès aux fichiers, et donc d’édition et de compilation.
Soyez patients
Il faut ensuite lancer les tests unitaires, et ne pas se précipiter immédiatement sur l’icône permettant de consulter les résultats de la couverture de code, sous peine de voir le message ci-dessous :
Et voila : arrivés ici, vous pourrez enfin voir vos informations de couverture de code. Je n’ai pas eu les problèmes supplémentaires exposés sur http://www.lgmorand.com/blog/post/2010/06/08/Mettre-en-place-du-code-coverage-avec-Visual-Studio-2010.aspx bien que j’utilise également TFS, mais à la place j’ai eu quelques autres effets de bord sans gravité…
