Udostępnij za pośrednictwem

Dostosowywanie analizy pokrycia kodu

  • Artykuł

Domyślnie narzędzie pokrycie kodu w usłudze Visual Studio analizuje wszystkie zestawów rozwiązania (.exe/.dll), które zostały załadowane podczas testów jednostkowych.Zaleca się zachować to ustawienie domyślne, ponieważ w większości przypadków działa ono prawidłowo.Aby uzyskać więcej informacji, zobacz Korzystanie z pokrycia kodu do określania, jaka część kodu jest poddawana testom.

Przed rozpoczęciem dostosowywania zachowanie pokrycie kodu, należy wziąć pod uwagę pewnych:

  • Chcę wykluczyć z wyników pokrycie kodu kodu testu i dodać tylko kod aplikacji.

    Dodaj ExcludeFromCodeCoverage atrybutu do własnej klasy testu.

  • Chcę dołączyć zestawów, które nie są częścią mojego do rozwiązania.

    Uzyskaj pliki .pdb dla tych zestawów i skopiuj je do tego samego folderu, co pliki .dll zestawu.

Aby dostosować zachowanie pokrycie kodu, skopiuj Przykładowy na końcu tego tematu i dodaj go do rozwiązania przy użyciu .runsettings rozszerzenia pliku.Edytuj go do własnych potrzeb, a następnie na testu menu, wybierz ustawień testu, Wybierz ustawienia testu pliku.W pozostałej części tego tematu opisano tę procedurę bardziej szczegółowo.

Plik .runsettings

Zaawansowane ustawienia pokrycia kodu są określone w pliku .runsettings.Jest to plik konfiguracji używany przez narzędzia do testowania jednostkowego.Firma Microsoft zaleca się skopiowanie Przykładowy na końcu tego tematu i edytować go do własnych potrzeb.

Aby dostosować pokrycie kodu, należy dodać plik .runsettings do rozwiązania:

  1. Dodaj jako element rozwiązania z rozszerzeniem pliku .xml .runsettings:

    W Eksploratorze rozwiązań, w menu skrótów rozwiązania, wybierz polecenie Dodaj, Nowy element, i wybierz pliku XML.Zapisz plik z nazwą zakończenia, takich jak CodeCoverage.runsettings

  2. Dodaj zawartość podaną w próbie na końcu tego tematu, a następnie dostosuj go do własnych potrzeb zgodnie z opisem w poniższych sekcjach.

  3. Na testu menu, wybierz polecenie ustawień testu, Wybierz ustawienia testu i wybierz plik.

  4. Teraz po uruchomieniu analizy pokrycia kodu, to .runsettings pliku sterowania jego działania.Nie zapomnij, że należy ponownie uruchomić pokrycie kodu: Twoje poprzednie wyniki pokrycia i kolorowanie kodu nie są automatycznie ukrywane podczas uruchamiania testów czy aktualizowania kodu.

  5. Niestandardowe ustawienia wyłączeniu i włączeniu, usuń zaznaczenie lub wybierz plik w testu, ustawień testu menu.

Test menu ustawień z pliku ustawień niestandardowych

Inne aspekty testów jednostkowych można skonfigurować w tym samym pliku .runsettings.Aby uzyskać więcej informacji, zobacz Weryfikowanie kodu przy użyciu testów jednostkowych.

Określanie ścieżek wyszukiwania symbolu

Pokrycie kodu wymaga symboli (pliki .pdb), aby były obecne zestawy.Dla zestawów zbudowanych według rozwiązania pliki symboli są zwykle obecne obok plików binarnych, a pokrycie kodu działa automatycznie.Jednak w niektórych przypadkach można chcieć dołączyć odwołania do zestawów do analizy pokrycia kodu.W takich przypadkach pliki .pdb mogą nie być przylegającymi do plików binarnych, ale ścieżkę wyszukiwania symbolu można określić w pliku .runsettings.

         <SymbolSearchPaths>              
               <Path>\\mybuildshare\builds\ProjectX</Path>
               <!--More paths if required-->
         </SymbolSearchPaths>
Informacje dotyczące przestrogiPrzestroga

Rozpoznawanie symboli może potrwać, szczególnie przy używaniu zdalnej lokalizacji pliku z wieloma zestawami.W związku z tym należy wziąć pod uwagę kopiowanie zdalnych plików .pdb do tej samej lokalizacji lokalnej co pliki binarne (.dll i .exe).

Uwzględnianie i wykluczanie

Określone zestawy można wykluczyć z analizy pokrycia kodu.Na przykład:

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

Alternatywnie można określić zestawy, które powinny być włączone.Takie podejście ma tę wadę, że po dodaniu większej liczby zestawów do rozwiązania trzeba pamiętać, aby dodać je do listy:

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

Jeśli <Include> jest pusta, a następnie przetwarzania pokrycie kodu obejmuje wszystkie zestawów (pliki .dll i .exe), które są ładowane i dla której .pdb pliki można znaleźć, z wyjątkiem elementów, które odpowiadają klauzuli <Exclude> listy.

Include przetwarza się przed Exclude.

Wyrażenia regularne

Uwzględnij lub wyklucz węzły, używając wyrażeń regularnych.Aby uzyskać więcej informacji, zobacz Używanie wyrażeń regularnych w Visual Studio.Wyrażenia regularne nie są tym samym, co symbole wieloznaczne.W szczególności:

  1. . * ciąg znaków

  2. \. odpowiada kropki ".")

  3. \ (\\) odpowiada nawiasy "(")

  4. \\ odpowiada ogranicznik ścieżki pliku "\"

  5. ^ pasuje do początku ciągu

  6. $ pasuje do końca ciągu

We wszystkich dopasowaniach rozróżniana jest wielkość liter.

Na przykład:

<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>
Informacje dotyczące przestrogiPrzestroga

Jeśli występuje błąd w wyrażeniu regularnym, taki jak nawiasy niedopasowane lub o niezmienionym znaczeniu, analiza pokrycia kodu nie będzie działać.

Inne sposoby, aby dołączyć lub wykluczyć elementy

Zobacz Przykładowy na końcu tego tematu przykłady.

  • ModulePath — Zestawy określonej przez ścieżkę pliku zestawu.

  • CompanyName — odpowiada zestawów w atrybucie firmy.

  • PublicKeyToken — dopasowań podpisem zestawy token klucza publicznego.Na przykład dopasować wszystkich składników programu Visual Studio i rozszerzenia, należy użyć <PublicKeyToken>^B03F5F7F11D50A3A$</PublicKeyToken>.

  • Source — odpowiada elementy według nazwy ścieżki pliku źródłowego, w którym są zdefiniowane.

  • Attribute — elementy, do których dołączono określonego atrybutu jest zgodna.Podaj pełną nazwę atrybutu, łącznie z wyrazem „Atrybut” na końcu nazwy.

  • Function — odpowiada w pełni kwalifikowaną nazwę procedury, funkcje i metody.

Pasujące nazwy funkcji

Dane wyrażenie regularne musi odpowiadać w pełni kwalifikowanej nazwie funkcji, łącznie z przestrzenią nazw, nazwą klasy, nazwą metody i listą parametrów.Na przykład:

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

Jak określić pliki .runsettings podczas wykonywania testów

Aby dostosować ustawienia uruchamiania w testach programu Visual Studio

Wybierz testu, ustawień testu, Wybierz ustawienia testu i wybierz plik .runsettings.Plik pojawi się w menu Ustawienia testu, gdzie można zaznaczyć go lub usunąć.Gdy zaznaczony plik .runsettings ma zastosowanie przy każdym użyciu analizy pokrycia kodu.

Dostosowywanie ustawień uruchamiania w teście wiersza polecenia

Aby uruchomić testy z wiersza polecenia, należy użyć narzędzia vstest.console.exe.Plik ustawień jest parametrem tego narzędzia.Aby uzyskać więcej informacji, zobacz Używanie narzędzia VSTest.console w wierszu poleceń.

  1. Uruchom wiersz polecenia deweloperów programu Visual Studio:

    W systemie Windows Start, wybierz polecenie Wszystkie programy, programu Microsoft Visual Studio, programu Visual Studio Tools, Developer wiersza polecenia.

  2. Uruchom:

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

Dostosowywanie ustawień wykonywania w definicji kompilacji

Możesz uzyskać dane pokrycia kodu z kompilacji zespołu.

Określanie runsettings w definicji kompilacji

  1. Upewnij się, że plik .runsettings jest zaewidencjonowany.

  2. Otwórz w programie Team Explorer tworzy, a następnie dodaj lub Edytuj definicję kompilacji.

  3. Na proces strony, a następnie rozwiń testy automatyczne, Testuj źródło, Uruchom ustawienia.Wybierz swoje .runsettings pliku.

    • Ale zestawu testów pojawia się zamiast Testuj źródło.Podczas próby ustawienia Uruchom ustawienia pole, można wybrać tylko pliki .testsettings.

      W obszarze testy automatyczne, wybierz opcję zestawu testów, i wybierz polecenie [...] na końcu wiersza.W Uruchom Test dodawać i edytować okno dialogowe, zestaw Narzędzie Test Runner do programu Visual Studio Test Runner.

Wyniki są widoczne w sekcji podsumowania raportu kompilacji.

Przykładowy plik .runsettings

Skopiuj ten kod i dostosuj go do swoich potrzeb.Jest to domyślny plik .runsettings.

(Do innych celów pliku .runsettings, zobacz Konfigurowanie testów jednostkowych przy użyciu pliku .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>

Pytania i odpowiedzi

  • Co się stało z plikiem .testsettings używanym w programie Visual Studio 2010?

    W programie Visual Studio 2010 plik .testsettings stosuje się jedynie do testów jednostkowych opartych na środowisku MSTest.Z programu Visual Studio 2012 narzędzia testowania stosuje się nie tylko do MSTest, ale także inne struktury, takich jak NUnit i xUnit.NET.Plik .testsettings nie będzie z nimi działać.Plik .runsettings ma na celu dostosowanie narzędzi testowych w sposób, który działa w przypadku wszystkich środowisk testowania.

Zobacz też

Koncepcje

Weryfikowanie kodu przy użyciu testów jednostkowych

Inne zasoby

Korzystanie z pokrycia kodu do określania, jaka część kodu jest poddawana testom