Personnalisation de l'analyse de couverture du code

Article
03/12/2013

Par défaut, l'outil de couverture du code de Visual Studio 2012 analyse les assemblys de solution (.exe/.dll) qui sont chargés pendant les tests unitaires.Nous vous recommandons de conserver la valeur par défaut, parce que cela fonctionne bien le plus souvent.Pour plus d'informations, consultez Utilisation de la couverture du code pour déterminer la quantité de code testé.

Avant de personnaliser le comportement de la couverture du code, tenez compte des possibilités :

Je souhaite exclure le code de test des résultats de la couverture du code et inclure uniquement le code d'application.

Ajoutez ExcludeFromCodeCoverage Attribute à votre classe de test.
Je souhaite incorporer des assemblys qui ne font pas partie de ma solution.

Obtenez les fichiers .pdb de ces assemblys et copiez-les dans le même répertoire que les fichiers de l'assembly .dll.

Pour personnaliser le comportement de couverture du code, copiez l' exemple à la fin de cette rubrique et ajoutez-le à votre solution à l'aide de l'extension de fichier .runsettings.Modifiez le à vos besoins, puis dans le menu Test , choisissez Paramètres de test, fichier Paramètres de test sélectionnés .La suite de cette rubrique décrit cette procédure plus en détail.

Le fichier de .runsettings

Les fonctionnalités avancées de couverture du code sont spécifiées dans un fichier .runsettings.Il s'agit du fichier de configuration utilisé par les outils de test unitaire.Nous vous recommandons de copier l' exemple à la fin de cette rubrique et de l'éditer selon vos besoins.

Qu'est-il arrivé au fichier .testsettings que j'utilisais dans Visual Studio 2010 ?

Dans Visual Studio 2010, le fichier .testsettings s'applique uniquement aux tests unitaires sur l'infrastructure MSTest.Dans Visual Studio 2012, les outils de test ne s'appliquent pas uniquement au framework MSTest, mais également à d'autres infrastructures telles que NUnit et à xUnit.net.Le fichier .testsettings ne fonctionnera pas avec ces derniers.Le fichier .runsettings est conçu pour personnaliser les outils de test d'une façon que cela fonctionne avec tout les frameworks de test.

Pour personnaliser la couverture du code, vous devez ajouter un fichier .runsettings à votre solution :

Ajoutez un fichier .xml comme élément de solution avec l'extension .runsettings:

Dans l'explorateur de solutions, dans le menu contextuel de votre solution, choisissez Ajouter, Nouvel élément, puis sélectionnez Fichier XML.Enregistrez le fichier avec un nom se terminant comme CodeCoverage.runsettings
Ajoutez le contenu fourni dans l'exemple à la fin de cette rubrique, puis personnalisez-le à vos besoins comme décrit dans les sections suivantes.
Dans le menu Test , choisissez Paramètres de test, Sélectionnez le fichier de paramètres de test et sélectionnez le fichier.
Maintenant quand vous exécutez Test, analysez la couverture du code, ce fichier .runsettings vérifiera son comportement.
Pour activer ou désactiver les paramètres personnalisés, désélectionnez ou séléctionnez le fichier dans Test, menu Paramètres de test .

Menu Paramètres de test avec le fichier de paramètres de test

D'autres aspects des tests unitaires peuvent être configurés dans le même fichier de .runsettings.Pour plus d'informations, consultez Vérification du code à l'aide de tests unitaires.

Spécifier les chemins de recherche de symboles.

La couverture du code requiert que des symboles (.pdb) pour les assemblys soient présents.Pour les assemblys générés par votre solution, les fichiers de symboles sont généralement présents à côté des fichiers binaires, et la couverture du code s'exécute automatiquement.Mais dans certains cas, vous pouvez inclure les assemblys référencés dans votre analyse de couverture du code.Dans ce cas, les fichiers .pdb peuvent ne pas être à côté des binaires, mais vous pouvez spécifier le chemin de recherche de symboles dans le fichier .runsettings.

         <SymbolSearchPaths>              
               <Path>\\mybuildshare\builds\ProjectX</Path>
               <!--More paths if required-->
         </SymbolSearchPaths>

Attention
La résolution de symboles peut prendre du temps, surtout lorsque vous utilisez un emplacement de fichier distant avec de nombreux assemblys.Par conséquent, envisagez de copier les fichiers distants .pdb au même emplacement local que les fichiers binaires (.dll et .exe).

Exclusion et inclusion

Vous pouvez exclure les assemblys spécifiés de l'analyse de couverture du code.Par exemple :

<ModulePaths>
  <Exclude>
   <ModulePath>Fabrikam.Math.UnitTest.dll</ModulePath>
   <!-- Add more ModulePath nodes here. -->
  </Exclude>
</ModulePaths>

Sinon, vous pouvez spécifier quelles assemblys doivent être incluses.Cette approche a l'inconvénient qui est que lorsque vous ajoutez des assemblys à la solution, vous devez penser à les ajouter à la liste :

<ModulePaths>
  <Include>
   <ModulePath>Fabrikam.Math.dll</ModulePath>
   <!-- Add more ModulePath nodes here. -->
  </Include>
</ModulePaths>

Si <Include> est vide, le traitement de couverture du code inclut toutes les assemblys (fichiers .dll et .exe) qui sont chargés et pour lequel les fichiers .pdb sont trouvés, à l'exception des éléments qui correspondent à une clause dans une liste d' <Exclude> .

Include est traité avant Exclude.

Expressions régulières

Les noeuds inclure et exclure utilisent des expressions régulière.Pour plus d'informations, consultez Utilisation d'expressions régulières dans Visual Studio.Les expressions régulières ne sont pas équivalent à des caractères génériques.En particulier :

.* correspond à une chaîne de nimporte quel caractères
\. correspond à un point ".")
 correspond à des parenthèses "( )"
\\ correspond à un séparateur de chemin de fichier "\ "
^ correspond au début de la chaîne
$ correspond la fin de la chaîne.

Toutes les correspondances ne respectent pas la casse.

Par exemple :

<ModulePaths>
  <Include>
    <!-- Include all loaded .dll assemblies (but not .exe assemblies): -->
    <ModulePath>.*\.dll$</ModulePath>
  </Include>
  <Exclude>
    <!-- But exclude some assemblies: -->
    <ModulePath>.*\\Fabrikam\.MyTests1\.dll$</ModulePath>
    <!-- Exclude all file paths that contain "Temp": -->
    <ModulePath>.*Temp.*</ModulePath> 
  </Exclude>
</ModulePaths>

Attention
S'il existe une erreur dans une expression régulière, telle qu'une séquence d'échappement ou une parenthèse non correspondance, l'analyse de couverture du code ne fonctionnera pas.

D'autres façons d'inclure ou d'exclure des éléments

Consultez la section d'exemple à la fin de cette rubrique pour un exemple de balisage XAML.

ModulePath – Les assemblys spécifiés par le chemin d'accès de fichier d'assembly.
CompanyName – Correspond aux assemblys par l'attribut Société.
PublicKeyToken – Correspond aux assemblys signés par le jeton de clé publique.Par exemple pour correspondre à tous les composants et extensions Visual Studio, utilisez <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>.
Source – éléments de correspondances par le chemin d'accès du fichier source dans lequel ils sont définis.
Attribute – éléments de correspondances auxquels un attribut spécial est attaché.Spécifiez le nom complet de l'attribut, y compris "Attribute" à la fin du nom.
Function – Corresponds des pocédures, des fonctions ou méthodes par le nom qualifié complet.

Faire correspondre un nom de fonction.

Votre expression régulière doit correspondre au nom complet de la fonction, y compris l'espace de noms, le nom de la classe, le nom de méthode et la liste de paramètres.Par exemple :

C# ou Visual Basic: Fabrikam.Math.LocalMath.SquareRoot(double)
C++: Fabrikam::Math::LocalMath::SquareRoot(double).

<Functions>
  <Include>
    <!-- Include methods in the Fabrikam namespace: -->
    <Function>^Fabrikam\..*</Function>
    <!-- Include all methods named EqualTo: -->
    <Function>.*.\EqualTo\(.*</Function>
  </Include>
  <Exclude>
    <!-- Exclude methods in a class or namespace named UnitTest: -->
    <Function>.*\.UnitTest\..*</Function>
  </Exclude>
</Functions>

Comment spécifiez les fichiers .runsettings pendant l'exécution des tests

Pour personnaliser des .runsettings dans les tests de Visual Studio

Choisisr Test, Paramètres de tests, Séléctionnez le fichier de paramètres de test et séléctionnez le fichier .runsettings.Le fichier apparaît dans le menu de paramètres de test, et vous pouvez le sélectionner ou l'annuler.Tant qu'il est sélectionné, votre fichier .runsettings s'applique lorsque vous utilisez Analysez la couverture du code.

Pour personnaliser les paramètres d'exécution d'un test en ligne de commande

Pour exécuter des tests à partir de la ligne de commande, utilisez vstest.console.exe.Le fichier de paramètre est un paramètre de cet utilitaire.Pour plus d'informations, consultez Utilisation de VSTest.Console à partir de la ligne de commande.

Exécutez l'invite de commande de développement Visual Studio :

Dans Windows Démarrer, choisissez Tous les programmes, Microsoft Visual Studio, Visual Studio Tools, Invite de commandes de développement.
Exécuter :

vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettings

Pour personnaliser des paramètres d'exécution dans une définition de build

Vous pouvez obtenir des données de couverture du code depuis un Team Build.

Spécification des paramètres d'exécution dans une définition de build

Assurez-vous que votre fichier .runsettings est archivé.
Dans Team Explorer, ouvrez Builds, puis ajouter ou modifier une définition de build.
Dans la page Processus , développez Tests automatisés, Source de test, Paramètres d'exécution.Sélectionnez votre fichier .runsettings .
- Mais Assembly de test apparaît au lieu Source de test.Lorsque j'essaie de définir le champ Paramètres d'exécution , je ne peux sélectionner que des fichiers .testsettings.
  
  Sous Tests automatisés, sélectionnez Assembly de test, puis choisissez [...] à la fin de la ligne.Dans la boîte de dialogue Ajoutez/Editez l'exécution de tests , définissez Test Runner, à Visual Studio Test Runner.

Les résultats sont visibles dans la section de résumé du rapport de build.

Fichier d'exemple .runsettings

Copiez ce code et modifiez-le selon vos besoins.Il s'agit du fichier par défaut .runsettings.

<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
        <Configuration>
          <CodeCoverage>
<!--
Additional paths to search for .pdb (symbol) files. Symbols must be found for modules to be instrumented.
If .pdb files are in the same folder as the .dll or .exe files, they are automatically found. Otherwise, specify them here.
Note that searching for symbols increases code coverage runtime. So keep this small and local.
--> 
<!--           
            <SymbolSearchPaths>              
                   <Path>C:\Users\User\Documents\Visual Studio 2012\Projects\ProjectX\bin\Debug</Path>
                   <Path>\\mybuildshare\builds\ProjectX</Path>
            </SymbolSearchPaths>
-->

<!--
About include/exclude lists:
Empty "Include" clauses imply all; empty "Exclude" clauses imply none.
Each element in the list is a regular expression (ECMAScript syntax). See https://msdn.microsoft.com/library/2k3te2cs.aspx.
An item must first match at least one entry in the include list to be included.
Included items must then not match any entries in the exclude list to remain included.
-->

            <!-- Match assembly file paths: -->
            <ModulePaths>
              <Include>
                <ModulePath>.*\.dll$</ModulePath>
                <ModulePath>.*\.exe$</ModulePath>
              </Include>
              <Exclude>
                <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
              </Exclude>
            </ModulePaths>

            <!-- Match fully qualified names of functions: -->
            <!-- (Use "\." to delimit namespaces in C# or Visual Basic, "::" in C++.)  -->
            <Functions>
              <Exclude>
                <Function>^Fabrikam\.UnitTest\..*</Function>         
                <Function>^std::.*</Function>
                <Function>^ATL::.*</Function>
                <Function>.*::__GetTestMethodInfo.*</Function>
                <Function>^Microsoft::VisualStudio::CppCodeCoverageFramework::.*</Function>
                <Function>^Microsoft::VisualStudio::CppUnitTestFramework::.*</Function>
              </Exclude>
            </Functions>

            <!-- Match attributes on any code element: -->
            <Attributes>
              <Exclude>
                <!-- Don’t forget "Attribute" at the end of the name -->
                <Attribute>^System.Diagnostics.DebuggerHiddenAttribute$</Attribute>
                <Attribute>^System.Diagnostics.DebuggerNonUserCodeAttribute$</Attribute>
                <Attribute>^System.Runtime.CompilerServices.CompilerGeneratedAttribute$</Attribute>
                <Attribute>^System.CodeDom.Compiler.GeneratedCodeAttribute$</Attribute>
                <Attribute>^System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute$</Attribute>
              </Exclude>
            </Attributes>

            <!-- Match the path of the source files in which each method is defined: -->
            <Sources>
              <Exclude>
                <Source>.*\\atlmfc\\.*</Source>
                <Source>.*\\vctools\\.*</Source>
                <Source>.*\\public\\sdk\\.*</Source>
                <Source>.*\\microsoft sdks\\.*</Source>
                <Source>.*\\vc\\include\\.*</Source>
              </Exclude>
            </Sources>

            <!-- Match the company name property in the assembly: -->
            <CompanyNames>
              <Exclude>
                <CompanyName>.*microsoft.*</CompanyName>
              </Exclude>
            </CompanyNames>

            <!-- Match the public key token of a signed assembly: -->
            <PublicKeyTokens>
              <!-- Exclude Visual Studio extensions: -->
              <Exclude>
                <PublicKeyToken>^B77A5C561934E089$</PublicKeyToken>
                <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>
                <PublicKeyToken>^31BF3856AD364E35$</PublicKeyToken>
                <PublicKeyToken>^89845DCD8080CC91$</PublicKeyToken>
                <PublicKeyToken>^71E9BCE111E9429C$</PublicKeyToken>
                <PublicKeyToken>^8F50407C4E9E73B6$</PublicKeyToken>
                <PublicKeyToken>^E361AF139669C375$</PublicKeyToken>
              </Exclude>
            </PublicKeyTokens>


            <!-- We recommend you do not change the following values: -->
            <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
            <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
            <CollectFromChildProcesses>True</CollectFromChildProcesses>
            <CollectAspDotNet>False</CollectAspDotNet>

          </CodeCoverage>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

Voir aussi

Concepts

Vérification du code à l'aide de tests unitaires

Autres ressources

Utilisation de la couverture du code pour déterminer la quantité de code testé

Share via