Anpassen der Codeabdeckungsanalyse

  • Artikel

Standardmäßig analysiert das Codeabdeckungstool von Visual Studio alle Projektmappenassemblys (.exe/.dll), die während der Komponententests geladen werden.Es wird empfohlen, diese Standardeinstellung beizubehalten, da sie meist gut funktioniert.Weitere Informationen finden Sie unter Bestimmen des Umfangs des zu testenden Codes mithilfe von Codeabdeckung.

Bevor Sie das Codeabdeckungsverhalten anpassen, berücksichtigen Sie einige Alternativen:

  • Ich möchte den Testcode aus den Codeabdeckungsergebnissen ausschließen und nur den Anwendungscode einbinden.

    Fügen Sie Ihrer Testklasse das Attribut ExcludeFromCodeCoverage hinzu.

  • Ich möchte die Assemblys einschließen, die nicht Teil meiner Projektmappe sind.

    Rufen Sie die PDB-Dateien für diese Assemblys ab, und kopieren Sie sie in den gleichen Ordner wie die Assemblydateien (DLL-Dateien).

Um das Codeabdeckungsverhalten anzupassen, kopieren Sie das Beispiel am Ende dieses Themas, und fügen Sie es der Projektmappe mit der Dateierweiterung ".runsettings" hinzu.Bearbeiten Sie das Beispiel Ihren eigenen Anforderungen entsprechend, und klicken Sie dann im Menü Test auf Testeinstellungen und auf Datei für Testeinstellungen auswählen.Im verbleibenden Teil dieses Themas werden diese Schritte ausführlicher beschrieben.

RUNSETTINGS-Datei

Erweiterte Codeabdeckungseinstellungen werden in einer RUNSETTINGS-Datei angegeben.Dies ist die Konfigurationsdatei, die von den Tools für Komponententests verwendet wird.Es wird empfohlen, das Beispiel am Ende dieses Themas zu kopieren und es an Ihre eigenen Anforderungen anzupassen.

Zur Anpassung der Codeabdeckung müssen Sie Ihrer Projektmappe eine RUNSETTINGS-Datei hinzufügen:

  1. Fügen Sie eine XML-Datei als Projektmappenelement mit der Erweiterung .runsettings hinzu:

    Wählen Sie im Projektmappen-Explorer im Kontextmenü der Projektmappe die Option Hinzufügen, Neues Element und XML-Datei aus.Speichern Sie die Datei mit einer Namensendung wie z. B. CodeCoverage.runsettings.

  2. Fügen Sie den Inhalt hinzu, der im Beispiel am Ende dieses Themas enthalten ist, und passen Sie diesen dann, wie in den folgenden Abschnitten beschrieben, an Ihre Anforderungen an.

  3. Klicken Sie im Menü Test auf Testeinstellungen, Datei für Testeinstellungen auswählen, und wählen Sie dann die Datei aus.

  4. Wenn Sie jetzt Codeabdeckung analysieren ausführen, steuert die RUNSETTINGS-Datei das Verhalten.Vergessen Sie nicht, dass Sie die Codeabdeckung erneut ausführen müssen: Die vorherigen Abdeckungsergebnisse und Codefarben werden nicht automatisch ausgeblendet, wenn Sie Tests ausführen oder den Code aktualisieren.

  5. Um die benutzerdefinierten Einstellungen ein- und auszuschalten, deaktivieren oder aktivieren Sie die Datei im Menü Test, Testeinstellungen.

Testeinstellungsmenü mit benutzerdefinierter Einstellungsdatei

Andere Aspekte von Komponententests können in derselben RUNSETTINGS-Datei konfiguriert werden.Weitere Informationen finden Sie unter Überprüfen von Code mithilfe von Komponententests.

Festlegen von Symbolsuchpfaden

Die Codeabdeckung erfordert Symbole (PDB-Dateien), damit Assemblys zur Verfügung stehen.Für über die Projektmappe erstellte Assemblys werden Symboldateien im Allgemeinen neben den Binärdateien bereitgestellt, und die Codeabdeckung funktioniert automatisch.In einigen Fällen sollten Sie jedoch Assemblys, auf die verwiesen wird, in die Codeabdeckungsanalyse einschließen.In solchen Fällen befinden sich die PDB-Dateien nicht neben den Binärdateien. Sie können jedoch den Symbolsuchpfad in der RUNSETTINGS-Datei angeben.

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

Die Symbolauflösung kann zeitaufwendig sein, insbesondere wenn sie einen Remotedateispeicherort mit zahlreichen Assemblys verwendet.Daher sollten Sie erwägen, die Remote-PDB-Dateien an denselben lokalen Speicherort wie die Binärdateien (DLL- und EXE-Dateien) zu kopieren.

Ausschließen und Einschließen

Sie können angegebene Assemblys von der Codeabdeckungsanalyse ausschließen.Beispiel:

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

Alternativ können Sie angeben, welche Assemblys enthalten sein sollen.Dieser Ansatz hat den Nachteil, dass Sie beim Hinzufügen von weiteren Assemblys zur Projektmappe daran denken müssen, diese der Liste hinzuzufügen:

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

Wenn <Include> leer ist, enthält die Verarbeitung der Codeabdeckung alle Assemblys (DLL- und EXE-Dateien), die geladen wurden und für die .pdb-Dateien gefunden werden können, ausgenommen der Elemente, die mit einer Klausel in der <Exclude>-Liste übereinstimmen.

Include wird vor Exclude verarbeitet.

Reguläre Ausdrücke

In den Knoten "include" und "exclude" werden reguläre Ausdrücke verwendet.Weitere Informationen finden Sie unter Verwenden von regulären Ausdrücken in Visual Studio.Reguläre Ausdrücke sind nicht identisch mit Platzhaltern.Insbesondere:

  1. .* entspricht einer Zeichenfolge beliebiger Zeichen

  2. \. entspricht einem Punkt "."

  3. \( \) entspricht Klammern "( )"

  4. \\ entspricht dem Dateipfadtrennzeichen "\"

  5. ^ entspricht dem Anfang der Zeichenfolge

  6. $ entspricht dem Ende der Zeichenfolge

Bei allen Entsprechungen wird die Groß-/Kleinschreibung nicht beachtet.

Beispiel:

<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>
WarnhinweisVorsicht

Wenn ein Fehler in einem regulären Ausdruck auftritt, z. B. eine Klammer ohne Escapezeichen und Übereinstimmung, wird die Codeabdeckungsanalyse nicht ausgeführt.

Andere Möglichkeiten zum Einschließen oder Ausschließen von Elementen

Ein Codebeispiel finden Sie am Ende dieses Themas.

  • ModulePath – Assemblys, die durch den Assemblydateipfad angegeben werden.

  • CompanyName – gleicht Assemblys nach dem Unternehmensattribut ab.

  • PublicKeyToken - gleicht signierte Assemblys nach dem öffentlichen Schlüsseltoken ab.Verwenden Sie beispielsweise <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>, um alle Visual Studio-Komponenten und -Erweiterungen abzugleichen.

  • Source – gleicht Elemente nach dem Pfadnamen der Quelldatei ab, in der sie definiert sind.

  • Attribute – gleicht Elemente ab, an die ein bestimmtes Attribut angefügt ist.Geben Sie den vollständigen Namen des Attributs, einschließlich "Attribut", am Ende des Namens an.

  • Function – gleicht Prozeduren, Funktionen oder Methoden nach dem vollqualifizierten Namen ab.

Abgleichen eines Funktionsnamens

Der reguläre Ausdruck muss mit dem vollqualifizierten Namen der Funktion, einschließlich Namespace, Klasse, Methodenname und Parameterliste, übereinstimmen.Beispiel:

  • C# oder 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>

So geben Sie RUNSETTINGS-Dateien beim Ausführen von Tests an

So passen Sie die RUNSETTINGS-Datei in Visual Studio-Tests an

Klicken Sie auf Test, Testeinstellungen, Datei für Testeinstellungen auswählen, und wählen Sie die RUNSETTINGS-Datei aus.Die Datei erscheint im Menü "Testeinstellungen", und Sie können sie auswählen oder abbrechen.Wenn die RUNSETTINGS-Datei ausgewählt ist, wird sie bei jeder Ausführung von Codeabdeckung analysieren angewendet.

So passen Sie Testlaufeinstellungen in einem Befehlszeilentest an

Um Tests über die Befehlszeile auszuführen, verwenden Sie "vstest.console.exe".Die Einstellungsdatei ist ein Parameter dieses Hilfsprogramms.Weitere Informationen finden Sie unter Verwenden von VSTest.console über die Befehlszeile.

  1. Starten der Visual Studio Developer-Eingabeaufforderung:

    Klicken Sie im Windows-Menü Start auf Alle Programme, Microsoft Visual Studio, Visual Studio-Tools und Developer-Eingabeaufforderung.

  2. Führen Sie Folgendes aus:

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

So passen Sie Testlaufeinstellungen in einer Builddefinition an

Sie können die Codeabdeckungsdaten von einem Teambuild abrufen.

Festlegen von Testlaufeinstellungen in einer Builddefinition

  1. Vergewissern Sie sich, dass die RUNSETTINGS-Datei eingecheckt ist.

  2. Öffnen Sie im Team Explorer Builds und fügen Sie dann eine Builddefinition hinzu oder bearbeiten Sie sie.

  3. Rufen Sie auf der Seite Prozess die Elemente Automatisierte Tests, Testquelle und Testlaufeinstellungen auf.Wählen Sie die .runsettings-Datei aus.

    • Es erscheint jedoch die Testassembly anstelle der Testquelle.Beim Versuch, das Feld Testlaufeinstellungen festzulegen, kann ich nur TESTSETTINGS-Dateien auswählen.

      Wählen Sie unter Automatisierte Tests die Option Testassembly aus, und klicken Sie am Ende der Zeile auf [...].Setzen Sie im Dialogfeld Testlauf hinzufügen/bearbeiten den Test Runner auf Visual Studio Test Runner.

Die Ergebnisse sind im zusammenfassenden Abschnitt des Buildberichts sichtbar.

Beispiel für eine RUNSETTINGS-Datei

Kopieren Sie diesen Code, und passen Sie ihn Ihren Anforderungen entsprechend an.Dies ist die standardmäßige RUNSETTINGS-Datei.

(Informationen zu anderen Verwendungsmöglichkeiten der RUNSETTINGS-Datei finden Sie unter Konfigurieren von Komponententests mithilfe einer .runsettings-Datei.)

<?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>

Fragen und Antworten

  • Was ist mit der TESTSETTINGS-Datei geschehen, die in Visual Studio 2010 verwendet wurde?

    In Visual Studio 2010 wird die TESTSETTINGS-Datei nur auf Komponententests angewendet, die auf dem MSTest-Framework basieren.In Visual Studio 2012 können die Testtools nicht nur auf MSTest, sondern auch auf andere Frameworks wie NUnit und xUnit angewendet werden.net.Die TESTSETTINGS-Datei funktioniert nicht mit diesen Frameworks.Die RUNSETTINGS-Datei wurde entwickelt, um die Testtools so anzupassen, dass sie in allen Testframeworks funktionieren.

Siehe auch

Konzepte

Überprüfen von Code mithilfe von Komponententests

Weitere Ressourcen

Bestimmen des Umfangs des zu testenden Codes mithilfe von Codeabdeckung