En effet, si vous utilisez du code généré (et notamment les datasets typés), ceux-ci ne génèrent pas toujours correctement l’attribut GeneratedCodeAttribute.

C’est un bug connu qui est normalement corrigé dans vs2010 (j’avoue ne pas avoir testé encore).

A noter qu’un nouvel attribut sera disponible avec le framework 4.0, il s’agit de [ExcludeFromCodeCoverage].

Un peu de patience et nous aurons des superbes taux de couverture de code

comme vu ici, il suffit de copier la dll dbghelp.dll, située dans le même répertoire que Microsoft.VisualStudio.Coverage.Analysis.dll, avec son programme/tache msbuild servant à automatiser l’extraction.

Chapeau, il fallait le trouver.

Comme vu dans ce billet : La couverture de code avec Visual Studio, visual studio peut nous générer un rapport de couverture de code une fois les tests unitaires joués.

Dans un processus d’intégration continue il est envisageable de programmer l’exécution des tests unitaires à date précise via une tache msbuild. Il est également possible de générer un rapport de couverture de code automatiquement. Cependant, pour le consulter, on sera obligé d’ouvrir un visual studio et de charger les tests correspondant.

Nous allons voir ici une solution pour extraire par code le résultat de la couverture de code afin de l’envoyer par exemple par mail au développeur.

Premier constat, les résultats des tests sont générés dans un répertoire de ce genre :

C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]

avec comme sous répertoire

• C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]\In\[Nom Machine]
• C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]\Out\

Dans le premier on va trouver un fichier data.coverage qui contient le résultat de la couverture de code, mais pour l’instant inexploitable.

Et dans le deuxième nos dll mises en jeu par le test.

On va pouvoir se servir des dll fournies par visual studio pour la couverture de code pour extraire un fichier xml contenant le résultat de la couverture de code.

On pourra ensuite effectuer une transformation de ce xml avec un xslt et générer un rapport html que nous pourrons envoyer par mail.

Voyons grosso modo le code mis en jeu, pour ce faire on utilisera l’assembly Microsoft.VisualStudio.Coverage.Analysis :

   1: using Microsoft.VisualStudio.CodeCoverage;

   2:  

   3: // extraction d'un fichier xml à partir du fichier data.coverage

   4: CoverageInfoManager.SymPath = @"C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]\Out\";

   5: CoverageInfoManager.ExePath = @"C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]\Out\";

   6:  

   7: CoverageInfo ci = CoverageInfoManager.CreateInfoFromFile(@"C:\TestResults\[Nom Utilisateur]_[Nom machine] [date] [heure]\In\[Nom Machine]\data.coverage");

   8: CoverageDS data = ci.BuildDataSet(null);

   9:  

  10: data.WriteXml(@"c:\result.xml");

  11:  

  12: // effectuer la transformation du xml 

  13: // envoyer le mail

Si on utilise des taches msbuild, on pourra avoir accès à tout un tas de variable d’environnement, dont une particulière $(TestResultsRoot) qui permet d’obtenir le repertoire de destination des tests, dans mon exemple il s’agit de C:\TestResults\

Ainsi, en passant la valeur de cette variable à notre programme (disons un programme console pour l’instant), on pourra être capable par code de :

• récupérer le dernier répertoire créé
• d’obtenir le répertoire de sortie
• d’obtenir le chemin du fichier data.coverage
• et de générer le fichier xml dans un fichier temporaire

   1: public static string GetCoverageTemporaryFileName(string baseDirectory) // baseDirectory est le nom du répertoire passé en paramètre

   2: {

   3:     var elts = Directory.GetDirectories(baseDirectory).Select(directory => new KeyValuePair<string, DateTime>(directory, Directory.GetCreationTime(directory))).OrderByDescending(value => value.Value).Select(v => v.Key);

   4:     if (elts.Any())

   5:     {

   6:         string directory = elts.First();

   7:         if (!directory.EndsWith(@"\"))

   8:             directory += @"\";

   9:         string outputPath = string.Format("{0}Out", directory);

  10:  

  11:         if (!Directory.Exists(outputPath))

  12:             throw new Exception("Impossible de trouver le répertoire de sortie, le répertoire " + outputPath + " n'existe pas");

  13:  

  14:         CoverageInfoManager.SymPath = outputPath;

  15:         CoverageInfoManager.ExePath = outputPath;

  16:  

  17:         string inputPath = string.Format("{0}\\In\\{1}\\data.coverage", directory, Environment.MachineName);

  18:         if (!File.Exists(inputPath))

  19:             throw new Exception("Impossible de trouver le fichier de couverture de code, le fichier " + inputPath + " n'existe pas");

  20:  

  21:         CoverageInfo ci = CoverageInfoManager.CreateInfoFromFile(inputPath);

  22:         CoverageDS data = ci.BuildDataSet(null);

  23:  

  24:         string tempFileName = Path.GetTempFileName();

  25:  

  26:         data.WriteXml(tempFileName);

  27:         return tempFileName;

  28:     }

  29:     return null;

  30: }

La suite dans le billet suivant : http://blog.developpez.com/nico-pyright/p8382/test/test-c-comment-extraire-la-couverture-de-3

Le xml obtenu a la tête suivante :

Une fois ce fichier xml obtenu, on pourra lui appliquer une transformation xsl. Pour ce faire, j’ai écrit ce xsl tout simple qui gagnerait grandement a être amélioré :

   1: <?xml version="1.0" encoding="iso-8859-1" ?>

   2: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

   3:   <xsl:output method="html"/>

   4:   <xsl:decimal-format name="financial" decimal-separator="," grouping-separator=" " />

   5:   <xsl:template match="/CoverageDSPriv">

   6:     <html>

   7:       <head>

   8:         <title></title>

   9:       </head>

  10:       <body>

  11:         <xsl:for-each select="Module">

  12:           <table border="1">

  13:             <tr>

  14:               <td>

  15:                 <xsl:value-of select="ModuleName" />

  16:               </td>

  17:               <td></td>

  18:               <td>Not Covered</td>

  19:               <td>Covered</td>

  20:             </tr>

  21:             <xsl:for-each select="NamespaceTable/Class">

  22:               <tr>

  23:                 <td>

  24:                   <xsl:value-of select="ClassName" />

  25:                 </td>

  26:                 <td></td>

  27:                 <td></td>

  28:                 <td></td>

  29:               </tr>

  30:               <xsl:for-each select="Method">

  31:                 <tr>

  32:                   <td></td>

  33:                   <td>

  34:                     <xsl:value-of select="MethodFullName" />

  35:                   </td>

  36:                   <td>

  37:                     <xsl:value-of select="format-number(BlocksNotCovered * 100 div (BlocksCovered + BlocksNotCovered),'# ##0,00','financial')" />%

  38:                   </td>

  39:                   <td>

  40:                     <xsl:value-of select="format-number(BlocksCovered * 100 div (BlocksCovered + BlocksNotCovered),'# ##0,00','financial')" />%

  41:                   </td>

  42:                 </tr>

  43:               </xsl:for-each>

  44:             </xsl:for-each>

  45:           </table>

  46:           <br/>

  47:         </xsl:for-each>

  48:       </body>

  49:     </html>

  50:   </xsl:template>

  51: </xsl:stylesheet>

J’ai placé le fichier xsl en ressource, ce qui fait qu’on pourra effectuer la transformation ainsi :

   1: public static string TransformCoverage(string file)

   2: {

   3:     StreamReader sr = new StreamReader(file);

   4:     XmlReader xmlReader = XmlReader.Create(sr);

   5:  

   6:     Assembly assembly = Assembly.GetExecutingAssembly();

   7:     Stream reader = assembly.GetManifestResourceStream("MyNamespace.output.xsl");

   8:  

   9:     if (reader != null)

  10:     {

  11:         // on transforme le xsl

  12:         XmlReader xslReader = XmlReader.Create(reader);

  13:         XslCompiledTransform xslt = new XslCompiledTransform();

  14:         xslt.Load(xslReader);

  15:  

  16:         StringBuilder sb = new StringBuilder();

  17:         TextWriter tw = new StringWriter(sb);

  18:         xslt.Transform(xmlReader, new XsltArgumentList(), tw);

  19:  

  20:         string value = sb.ToString();

  21:  

  22:         tw.Close();

  23:         xslReader.Close();

  24:         reader.Close();

  25:         return value;

  26:     }

  27:     xmlReader.Close();

  28:     sr.Close();

  29:     throw new Exception("Impossible de récupérer le fichier xsl");

  30: }

Il ne restera plus qu’à envoyer le mail, avec quelque chose du genre :

   1: MailAddress from = new MailAddress("from@email.com");

   2: MailMessage mailMessage = new MailMessage { From = from };

   3: mailMessage.To.Add(new MailAddress("to@email.com"););

   4:  

   5: mailMessage.Subject = "Rapport de couverture de code";

   6: mailMessage.IsBodyHtml = true;

   7: mailMessage.Body = body; // résultat de TransformCoverage

   8:  

   9: SmtpClient smtpClient = new SmtpClient(smtpAddress);

  10: smtpClient.Send(mailMessage);

Et voilà pour l’extraction de la couverture de code avec du code C#

On obtient le résultat suivant :

Visual Studio (notamment dans sa version Visual Studio Team System Test Edition) permet de mesurer la couverture du code de nos tests unitaires.

Prenons par exemple cette classe :

   1: public class Class1

   2: {

   3:     public int DoStuff()

   4:     {

   5:         return 10;

   6:     }

   7:  

   8:     public void DoStuffJamaisAppelee()

   9:     {

  10:         throw new NotImplementedException();

  11:     }

  12: }

et la classe de test associée :

   1: [TestClass]

   2: public class UnitTest1

   3: {

   4:     [TestMethod]

   5:     public void TestMethod1()

   6:     {

   7:         Class1 class1 = new Class1();

   8:         int result = class1.DoStuff();

   9:         Assert.AreEqual(10, result);

  10:     }

  11: }

On a beau avoir tous nos tests qui passent :

On voit bien, en observant le code de notre classe de test, que seule la méthode DoStuff est couverte alors que la méthode DoStuffJamaisAppelee n’est jamais testée.

Dans ce cas simple, il est facile de se rendre compte qu’il faut rajouter un test appelant la méthode DoStuffJamaisAppelee pour être bien sur que l’ensemble de notre code est couvert par des tests unitaires. Mais si le code se rallonge, comment être bien sur que l’on oublie rien ?

C’est la qu’intervient l’outil de couverture de code (disponible uniquement dans certaines éditions de visual studio). Je peux obtenir un rapport sur mes tests unitaires :

A la lecture du tableau, on se rend bien compte que DoStuff est couverte à 100% et que DoStuffJamaisAppelee aurait bien besoin d’un petit test unitaire…

De plus, en double-cliquant sur les méthodes dans le rapport, Visual Studio nous amène dans notre code source et nous signale en couleur les éléments dans lesquels les tests ne sont pas passés.

Prenons par exemple cette classe :

   1: public class Class1

   2: {

   3:     public bool DoStuff(int val)

   4:     {

   5:         if (val == 10)

   6:             return false;

   7:         return true; ;

   8:     }

   9: }

Avec la méthode de test suivante :

   1: [TestClass]

   2: public class UnitTest1

   3: {

   4:     [TestMethod]

   5:     public void TestMethod1()

   6:     {

   7:         Class1 class1 = new Class1();

   8:         bool result = class1.DoStuff(5);

   9:         Assert.AreEqual(true, result);

  10:     }

  11: }

Ici, en double cliquant sur la méthode DoStuff, on arrive dans le fichier source concerné avec :

Et on voit tout de suite ce qui ne va pas, il manque un test de la méthode DoStuff avec en paramètre la valeur 10. Il ne reste plus qu’à rajouter le test adéquat et la couverture sera complète.

Voilà pour un aperçu de la couverture de code, outil indispensable pour qui veut être bien sur de la pertinence de ses tests unitaires

Si c’est possible, je recommande d’utiliser plutôt le qualificateur

plutôt que

Dans ce cas, il devient possible d’utiliser l’attribut InternalsVisibleTo afin d’indiquer que le projet de test pourra accéder aux classes/méthodes internes.

Cela se fait en renseignant cet attribut dans le fichier AssemblyInfo.cs du projet contenant la classe interne. On lui indique l’assembly qui sera autorisée à utiliser les éléments internes de la classe.

Par exemple :

   1: [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("MonAssembly, PublicKey=laclepubliquesibesoin")]

Notez que si l’assembly est signée, il faudra renseigner la clé publique complète, que l’on peut trouver grâce à la commande :

On pourra également utiliser l’assistant de Visual Studio, grâce au menu contextuel qui s’affiche lors du clic sur le bouton droit :

Il suffira de choisir la méthode interne à tester :

Une autre solution est de, toujours avec l’assistant, demander à Visual Studio de générer un accesseur privé afin de pouvoir tester les méthodes privées.

Grâce au menu contextuel, on peut :

Il génère dans le projet de test l’accesseur privé :

et on pourra utiliser un code du genre pour tester sa méthode privée :

   1: MonWebService_Accessor test = new MonWebService_Accessor();

   2: int value = test.UneMethodePrivate();

   3: Assert.AreEqual(10, value);

Voilà pour le test de méthode privée.

Or, bien que cela soit possible de lancer à la main le serveur à travers visual studio et d’effectuer des tests, cela devient problématique pour toute utilisation automatisée ou souhaitant tourner dans un environnement où aucun serveur web n’est lancé.

Comment faire alors pour tester son web service ?

Une solution est d’utiliser la DLL WebDev.WebHost.dll comme décrit ici par Phil Haack.

Je vais vous présenter ici cette solution en m’inspirant du post de Phil.

La première chose à faire est d’avoir un projet de test et (temporairement) d’avoir le projet contenant le svc en train de s’exécuter afin de pouvoir naviguer sur le service web.

On ajoute une référence service, et on utilise le bouton discover pour trouver le service web.

Visual studio nous génère une classe proxy permettant d’appeler le web service.

Reste à référencer le projet WebServiceTestUtility que vous trouverez en pièces jointes et qui contient le code nécessaire pour instancier le serveur WebDev.WebHost automatiquement.

On aura besoin du fichier WebDev.WebHost.dll, il faudra aller l’extraire du GAC en y naviguant (via une invite de commande par exemple) et le copier dans son projet. Le projet WebServiceTestUtility y fait référence.

On instanciera la classe WebHostWebServer avec le port et l’adresse précisée dans le web.config, comme ici :

   1: [TestInitialize]

   2: public void MyTestInitialize()

   3: {

   4:     _webHostWebServer = new WebHostWebServer(58743, "/");

   5:     _webHostWebServer.Start();

   6:     _webHostWebServer.ExtractResource("MonServiceWCF.Tests.Unit.Resources.Web.config", "Web.config");

   7:     _webHostWebServer.ExtractResource("MonServiceWCF.Tests.Unit.Resources.MonWebService.svc", "MonWebService.svc");

   8: }

On remarque que l’appel à la méthode ExtractResource qui prend en paramètres deux fichiers, le web.config et le fichier svc. Ce sont des fichiers du web service qui devront être copiés dans le test unitaires et inclus en tant que ressource.

Il ne reste plus qu’à instancier la classe proxy et vérifier que tout se passe bien.

   1: [TestMethod]

   2: public void FaitQuelqueChose_EnUtilisantLeWebDevWebHost_EstFonctionnel()

   3: {

   4:     MonWebServiceClient monWebServiceClient = new MonWebServiceClient();

   5:     int value = monWebServiceClient.FaitQuelqueChose();

   6:  

   7:     Assert.AreEqual(10, value);

   8: }

Sans oublier de libérer les ressources en fin de test :

   1: [TestCleanup]

   2: public void MyTestCleanup()

   3: {

   4:     _webHostWebServer.Stop();

   5: }

Notez que pour s’exécuter correctement, le test a besoin de pouvoir accéder à la DLL qui contient l’implémentation du service. Il faudra donc soit l’ajouter en tant que référence au projet afin qu’elle soit copiée dans le répertoire de destination, soit exécuter une post-build event du type :

copy « $(SolutionDir)leRepertoire\$(OutDir)MonServiceWCF.dll » « $(TargetDir) »

Il n’y a plus qu’à tester :

Et voilà, prêt pour une intégration continue

Vous pouvez téléchargez les sources de l’exemple ici

• Arrange => initialiser les objets mis en jeu par le test
• Act => Exécuter la méthode que l’on souhaite tester
• Assert => Vérifier que les résultats sont conforme aux attentes

Je n’ai pas vu de traduction officielle de cette abréviation.

Que pensez-vous de :

• Arranger
• Agir
• Auditer

En avez vous d’autres à proposer ?

Bien sur, l’objectif est de garder les 3 A

Or, un test doit pouvoir se baser sur un contexte connu et le fait de tester des opérations CRUD sur sa base de données va forcément modifier ce contexte. On en déduit deux axes principaux :

• Avoir un contexte connu => i.e. avoir des valeurs dans la base de données
• Ne pas modifier le contexte => i.e. restaurer l’état de la base comme au début du test

Quelles sont les différentes pistes que nous pouvons explorer pour résoudre ce problème ?

• Ajouter, supprimer manuellement les données qui ont pu être supprimées, ajoutées à chaque test. Cela nécessite d’exécuter du sql en vrac à chaque test et peut être un travail laborieux et décourager le développeur quand les données sont nombreuses.
• Restaurer un dump de la base de données de test après chaque exécution du test. Cela est très problématique si la base de données est volumineuse.
• Avoir un moyen de mettre une base de données de test dans un certain état à chaque début de test, comme expliqué dans cet article : Unit Testing the Data Access Layer, par Tim Stall ou dans celui-ci : Get Test Infected with NUnit: Unit Test Your .NET Data Access Layer, par Steven A. Smith. Cela nécessite un gros travail pour mettre sa base en état (construction de script sql pour vider la base, construire la structure, ajouter les données, etc …) et un temps non négligeable d’exécution à chaque test. Cela peut aussi être gênant lorsqu’on travaille à plusieurs sur la même base de test.
• Avoir une base de données de test et exécuter chaque opération CRUD dans une transaction (par exemple la classe SqlTransaction), comme on peut le retrouver dans le livre Test-Driven Development in Microsoft .Net de James Newkirk et Alexei A. Vorontsov) qui sera ensuite annulée. Cela nécessite de rajouter du code spécifique dans nos tests pour créer et annuler la transaction.
• Utiliser COM+ entreprise services (ou COM+ 1.5) et utiliser une classe de base pour ses tests qui encapsule la création et l’annulation de la transaction, comme décrit dans l’article Simplify Data Layer Unit Testing using Enterprise Services de Roy Osherove. Cela nécessite d’avoir un provider ADO.NET qui supporte les transactions distribuées, ce qui est quand même le cas de bon nombre d’entre eux et nécessite d’exécuter que des commandes sql qui peuvent être utilisées dans une transaction distribuée.
• Des frameworks de test (MbUnit, XtUnit, NunitX) semblent utiliser des attributs à poser sur ses tests pour effectuer la restauration des données altérées)

Et vous, comment testez-vous vos DAL ?