Udostępnij za pośrednictwem


Konfigurowanie testów jednostkowych przy użyciu pliku .runsettings

Plik .runsettings może służyć do konfigurowania sposobu uruchamiania testów jednostkowych. Na przykład może służyć do zmiany wersji platformy .NET, w której są uruchamiane testy, katalogu wyników testów lub danych zebranych podczas przebiegu testu. Typowym zastosowaniem pliku .runsettings jest dostosowanie analizy pokrycia kodu.

Pliki runsettings mogą służyć do konfigurowania testów uruchamianych z poziomu wiersza polecenia, ze środowiska IDE lub w przepływie pracy kompilacji przy użyciu planów testowych platformy Azure lub serwera Azure DevOps Server (wcześniej znanego jako Team Foundation Server (TFS).

Pliki runsettings są opcjonalne. Jeśli nie potrzebujesz żadnej specjalnej konfiguracji, nie potrzebujesz pliku .runsettings .

Tworzenie pliku ustawień uruchamiania i dostosowywanie go

  1. Dodaj plik ustawień uruchamiania do rozwiązania. W Eksplorator rozwiązań w menu skrótów rozwiązania wybierz pozycję Dodaj>nowy element i wybierz pozycję Plik XML. Zapisz plik pod nazwą taką jak test.runsettings.

    Jeśli nie widzisz wszystkich szablonów elementów, wybierz pozycję Pokaż wszystkie szablony, a następnie wybierz szablon elementu.

    Napiwek

    Nazwa pliku nie ma znaczenia, o ile używasz rozszerzenia .runsettings.

  2. Dodaj zawartość z pliku Example *.runsettings, a następnie dostosuj ją do Twoich potrzeb zgodnie z opisem w poniższych sekcjach.

  3. Określ plik *.runsettings, który chcesz użyć jednej z następujących metod:

  4. Uruchom testy jednostkowe, aby użyć niestandardowych ustawień uruchamiania.

Jeśli chcesz wyłączyć i włączyć ustawienia niestandardowe w środowisku IDE, usuń zaznaczenie lub wybierz plik w menu Test .

Napiwek

W rozwiązaniu można utworzyć więcej niż jeden plik .runsettings i wybrać go jako plik aktywnych ustawień testu zgodnie z potrzebami.

Określanie pliku ustawień uruchamiania w środowisku IDE

Dostępne metody zależą od używanej wersji programu Visual Studio.

Program Visual Studio 2019 w wersji 16.4 lub nowszej

Istnieją trzy sposoby określania pliku ustawień uruchamiania w programie Visual Studio 2019 w wersji 16.4 lub nowszej.

Autowykrywanie pliku ustawień uruchamiania

Uwaga

Będzie to działać tylko dla pliku o nazwie .runsettings.

Aby automatycznie ustawić plik ustawień uruchamiania, umieść go w katalogu głównym rozwiązania.

Jeśli włączono automatyczne wykrywanie plików ustawień uruchamiania, ustawienia w tym pliku są stosowane we wszystkich uruchomionych testach. Automatyczne wykrywanie plików runsettings można włączyć przy użyciu dwóch metod:

  • Wybieranie opcji>Narzędzia>— Testowanie>automatycznego wykrywania plików ustawień uruchamiania

    Opcja automatycznego wykrywania pliku ustawień w programie Visual Studio

  • Wybierz pozycję Testuj>skonfiguruj ustawienia>uruchamiania Automatycznie wykrywaj pliki uruchamiania

    Automatycznie wykrywaj menu pliku runsettings w programie Visual Studio

Ręczne wybieranie pliku ustawień uruchamiania

W środowisku IDE wybierz pozycję Testuj>skonfiguruj ustawienia>uruchamiania Wybierz pozycję Plik szerokiego uruchomienia rozwiązania, a następnie wybierz plik .runsettings.

  • Ten plik zastępuje plik .runsettings w katalogu głównym rozwiązania, jeśli jest obecny, i jest stosowany we wszystkich uruchomionych testach.
  • Ten wybór pliku jest utrwalany tylko lokalnie.

Wybieranie menu pliku runsettings w całym rozwiązaniu testowym w programie Visual Studio

Ustawianie właściwości kompilacji

Dodaj właściwość kompilacji do projektu za pomocą pliku projektu lub pliku Directory.Build.props. Plik ustawień uruchamiania dla projektu jest określony przez właściwość RunSettingsFilePath.

  • Ustawienia uruchamiania na poziomie projektu są obecnie obsługiwane w projektach C#, VB, C++i F#.
  • Plik określony dla projektu zastępuje dowolny inny plik ustawień uruchamiania określony w rozwiązaniu.
  • Te właściwości programu MSBuild mogą służyć do określenia ścieżki do pliku runsettings.

Przykład określania pliku .runsettings dla projektu:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <RunSettingsFilePath>$(MSBuildProjectDirectory)\example.runsettings</RunSettingsFilePath>
  </PropertyGroup>
  ...
</Project>

Program Visual Studio 2019 w wersji 16.3 lub starszej

Aby określić plik ustawień uruchamiania w środowisku IDE, wybierz pozycję Testuj>wybierz pozycję Plik ustawień. Przejdź do pliku .runsettings i wybierz go.

Wybieranie menu pliku ustawień testu w programie Visual Studio 2019

Plik zostanie wyświetlony w menu Test i możesz go wybrać lub usunąć zaznaczenie. Wybrany plik ustawień uruchamiania ma zastosowanie zawsze wtedy, gdy wybierzesz pozycję Analizuj pokrycie kodu.

Określanie pliku ustawień uruchamiania z wiersza polecenia

Aby uruchomić testy z wiersza polecenia, użyj vstest.console.exe i określ plik ustawień przy użyciu /Settings parametru.

  1. Otwórz wiersz polecenia dla deweloperów dla programu Visual Studio.

  2. Wprowadź polecenie podobne do:

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

    lub

    vstest.console.exe --settings:test.runsettings test.dll
    

Aby uzyskać więcej informacji, zobacz VSTest.Console.exe opcje wiersza polecenia.

Plik *.runsettings

Plik *.runsettings jest plikiem XML zawierającym różne elementy konfiguracji w elemecie RunSettings . Sekcje, które zawierają szczegółowe informacje o różnych elementach. Pełny przykład można znaleźć w temacie Example *.runsettings file (Przykładowy plik *.runsettings).

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- configuration elements -->
</RunSettings>

Każdy z elementów konfiguracji jest opcjonalny, ponieważ ma wartość domyślną.

RunConfiguration, element

<RunConfiguration>
    <MaxCpuCount>1</MaxCpuCount>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
    <TargetPlatform>x86</TargetPlatform>
    <TargetFrameworkVersion>net6.0</TargetFrameworkVersion>
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>
    <TestCaseFilter>(TestCategory != Integration) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>
    <TestSessionTimeout>10000</TestSessionTimeout>
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
</RunConfiguration>

Element RunConfiguration może zawierać następujące elementy:

Węzeł Wartość domyślna Wartości
MaxCpuCount 1 Nazwa opcji uwzględnia wielkość liter i jest łatwa do misspell jako MaxCPUCount.

To ustawienie kontroluje poziom równoległości na poziomie procesu. Użyj wartości 0, aby włączyć maksymalny równoległość na poziomie procesu.

To ustawienie określa maksymalną liczbę bibliotek DLL testów lub innych kontenerów testowych, które mogą być uruchamiane równolegle. Każda biblioteka DLL jest uruchamiana we własnym procesie testhost i jest odizolowana na poziomie procesu od testów w innych testowych bibliotekach DLL. To ustawienie nie wymusza równoległego uruchamiania testów w każdej testowej biblioteki DLL. Kontrolowanie równoległego wykonywania w ramach biblioteki DLL (na poziomie wątku) zależy od struktury testowej, takiej jak MSTest, XUnit lub NUnit.

Wartość domyślna to 1, co oznacza, że tylko jeden host testowy jest uruchamiany w tym samym czasie. Wartość specjalna 0 umożliwia dowolną liczbę hostów testowych, ponieważ masz procesory logiczne (na przykład 6, dla komputera z 6 rdzeniami fizycznymi bez wielowątkowego lub 12, dla komputera z sześcioma rdzeniami fizycznymi z wielowątkiem).

Liczba unikatowych bibliotek DLL w przebiegu określa rzeczywistą liczbę uruchomionych hostów testowych.
ResultsDirectory Katalog, w którym są umieszczane wyniki testów. Ścieżka jest względna względem katalogu zawierającego plik .runsettings.
TargetFrameworkVersion net40 lub netcoreapp1.0 Pomiń ten cały tag w celu automatycznego wykrywania.

To ustawienie definiuje wersję platformy lub rodzinę platform do użycia do uruchamiania testów.

Akceptowane wartości to dowolny pseudonim platformy, taki jak , ,net6.0net472net5.0 , , netcoreapp3.1lub uap10.0 dowolna prawidłowa pełna nazwa struktury, taka jak net48.NETFramework,Version=v4.7.2 lub ..NETCoreApp,Version=v6.0.0 W przypadku zgodności z poprzednimi Framework35wersjami , , Framework40Framework45, FrameworkCore10, FrameworkUap10 są akceptowane, co oznacza (net35, net40, net45, netcoreapp1.0 i uap10.0 odpowiednio). Wszystkie wartości są bez uwzględniania wielkości liter.

Podana wartość służy do określania dostawcy środowiska uruchomieniowego testów do użycia. Każdy dostawca środowiska uruchomieniowego testów musi uwzględniać rodzinę platform, która ma być używana, ale może nie uwzględniać dokładnej wersji platformy:

W przypadku programu .NET Framework 4.5.1 — 4.8 jest używany host testowy utworzony przy użyciu określonej dokładnej wersji. W przypadku wartości spoza tego zakresu jest używany testhost programu .NET Framework 4.5.1.

W przypadku platformy .NET projekt <TargetFramework> testowy (lub dokładniej runtimeconfig.json) określa rzeczywistą wersję.

W przypadku platformy UWP aplikacja projektu testowego jest samym hostem testowym i określa rzeczywistą wersję używanej platformy UWP.

Pomiń TargetFrameworkVersion element z pliku .runsettings , aby automatycznie określić wersję platformy z skompilowanych plików binarnych.

Podczas autotekstrowania wszystkie struktury docelowe są ujednolicone w jednej wspólnej strukturze. Po znalezieniu innej wersji z tej samej rodziny platform docelowych zostanie wybrana nowsza wersja (na przykład net452, net472, net48 = net48).

W przypadku modułu uruchamiającego program .NET Framework (w programie Visual Studio lub vstest.console.exe w wierszu polecenia dla deweloperów) typową platformą docelową jest net40. W przypadku modułu uruchamiającego platformę .NET (dotnet test + DLL) typowa struktura docelowa jest ustawiona na netcoreapp1.0.
TargetPlatform x86 Pomiń ten cały tag w celu automatycznego wykrywania.

To ustawienie definiuje architekturę używaną do uruchamiania testów. Możliwe wartości to x86, , ARMx64, ARM64, S390x.

Podczas autotekstrowania architektura bibliotek DLL AnyCPU może się różnić w zależności od modułu uruchamiającego. W przypadku modułu uruchamiającego program .NET Framework (w programie Visual Studio lub vstest.console.exe w wierszu polecenia dla deweloperów) wartość domyślna to x86. W przypadku modułu uruchamiającego program .NET (dotnet test) wartość domyślna to bieżąca architektura procesu.

TreatTestAdapterErrorsAsWarnings fałsz fałsz, prawda
TestAdaptersPaths Co najmniej jedna ścieżka do katalogu, w którym znajdują się elementy TestAdapters
TestCaseFilter Wyrażenie filtru w wartości> operatora><właściwości><formatu<[|&<Wyrażenie>]. Operator logiczny & powinien być reprezentowany przez jednostkę HTML &. Wyrażenia można ujęć w nawiasy. Aby uzyskać szczegółową składnię struktury wyrażeń, zobacz vstest/docs/filter.md.
TestSessionTimeout Umożliwia użytkownikom zakończenie sesji testowej po przekroczeniu limitu czasu określonego w milisekundach. Ustawienie limitu czasu gwarantuje, że zasoby są dobrze używane, a sesje testowe są ograniczone do określonego czasu. To ustawienie jest dostępne w programie Visual Studio 2017 w wersji 15.5 lub nowszej.
DotnetHostPath Określ niestandardową ścieżkę do hosta dotnet, który jest używany do uruchamiania hosta testowego. Jest to przydatne podczas tworzenia własnej aplikacji dotnet, na przykład podczas kompilowania repozytorium dotnet/runtime. Określenie tej opcji pomija wyszukiwanie testhost.exe i wymusza użycie testhost.dll.
TreatNoTestsAsError fałsz prawda lub fałsz
Określ wartość logiczną, która definiuje kod zakończenia, gdy nie zostaną odnalezione żadne testy. Jeśli wartość jest true i nie zostaną odnalezione żadne testy, zwracany jest kod zakończenia niezerowy. W przeciwnym razie zwracane jest zero.

Element DataCollectors (karty danych diagnostycznych)

Element DataCollectors określa ustawienia kart danych diagnostycznych. Karty danych diagnostycznych zbierają dodatkowe informacje o środowisku i testowaniu aplikacji. Każda karta ma ustawienia domyślne i musisz podać tylko ustawienia, jeśli nie chcesz używać ustawień domyślnych.

<DataCollectionRunSettings>
  <DataCollectors>
    <!-- data collectors -->
  </DataCollectors>
</DataCollectionRunSettings>

Moduł zbierający dane codeCoverage

Moduł zbierający dane pokrycia kodu tworzy dziennik z zapisami, które części kodu aplikacji zostały wykonane w teście. Aby uzyskać szczegółowe informacje na temat dostosowywania ustawień pokrycia kodu, zobacz Dostosowywanie analizy pokrycia kodu.

<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>
      <ModulePaths>
        <Exclude>
          <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
        </Exclude>
      </ModulePaths>

      <UseVerifiableInstrumentation>True</UseVerifiableInstrumentation>
      <AllowLowIntegrityProcesses>True</AllowLowIntegrityProcesses>
      <CollectFromChildProcesses>True</CollectFromChildProcesses>
      <CollectAspDotNet>False</CollectAspDotNet>
    </CodeCoverage>
  </Configuration>
</DataCollector>

Moduł zbierający dane videoRecorder

Moduł zbierający dane wideo przechwytuje nagranie ekranu podczas uruchamiania testów. To nagranie jest przydatne w przypadku rozwiązywania problemów z testami interfejsu użytkownika. Moduł zbierający dane wideo jest dostępny w programie Visual Studio 2017 w wersji 15.5 lub nowszej. Aby zapoznać się z przykładem konfigurowania tego modułu zbierającego dane, zobacz przykładowy plik *.runsettings.

Aby dostosować dowolny inny typ kart danych diagnostycznych, użyj pliku ustawień testu.

Obwinianie modułu zbierającego dane

Ta opcja może pomóc wyizolować problematyczny test, który powoduje awarię hosta testowego. Uruchomienie modułu zbierającego powoduje utworzenie pliku wyjściowego (Sequence.xml) w elempcie TestResults, który przechwytuje kolejność wykonywania testu przed awarią.

Możesz uruchomić winę w trzech różnych trybach:

  • Tryb pliku sekwencji: aby utworzyć plik z listą testów do zawieszenia
  • Tryb zrzutu awaryjnego: aby utworzyć zrzut podczas awarii hosta testowego
  • Tryb zrzutu zawieszania: aby utworzyć zrzut, gdy test nie zakończy się przed upływem określonego limitu czasu

Konfiguracja XML powinna zostać umieszczona bezpośrednio w węźle <RunSettings> :

<RunSettings>
  <RunConfiguration>
  </RunConfiguration>
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="blame" enabled="True" />
    </Loggers>
  </LoggerRunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- Enables blame -->
      <DataCollector friendlyName="blame" enabled="True">
        <Configuration>
          <!-- Enables crash dump, with dump type "Full" or "Mini".
          Requires ProcDump in PATH for .NET Framework. -->
          <CollectDump DumpType="Full" />
          <!-- Enables hang dump or testhost and its child processes 
          when a test hangs for more than 10 minutes. 
          Dump type "Full", "Mini" or "None" (just kill the processes). -->
          <CollectDumpOnTestSessionHang TestTimeout="10min" HangDumpType="Full" />
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

TestRunParameters

<TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="docsUrl" value="https://learn.microsoft.com" />
</TestRunParameters>

Parametry przebiegu testu umożliwiają definiowanie zmiennych i wartości dostępnych dla testów w czasie wykonywania. Uzyskaj dostęp do parametrów przy użyciu właściwości MSTest TestContext.Properties (lub NUnit TestContext):

private string _appUrl;
public TestContext TestContext { get; set; }

[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
    string _appUrl = TestContext.Properties["webAppUrl"];
}

Aby użyć parametrów przebiegu testu, dodaj właściwość publiczną TestContext do klasy testowej.

LoggerRunSettings, element

Sekcja LoggerRunSettings definiuje jeden lub więcej rejestratorów, które mają być używane na potrzeby przebiegu testu. Najbardziej typowe rejestratory to konsola, plik wyników testów programu Visual Studio (trx) i html.

<LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="console" enabled="True">
        <Configuration>
            <Verbosity>quiet</Verbosity>
        </Configuration>
      </Logger>
      <Logger friendlyName="trx" enabled="True">
        <Configuration>
          <LogFileName>foo.trx</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="html" enabled="True">
        <Configuration>
          <LogFileName>foo.html</LogFileName>
        </Configuration>
      </Logger>
    </Loggers>
  </LoggerRunSettings>

MSTest, element

Te ustawienia są specyficzne dla karty testowej, która uruchamia metody testowe, które mają TestMethodAttribute atrybut.

<MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <ConsiderFixturesAsSpecialTests>False</ConsiderFixturesAsSpecialTests>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
</MSTest>
Konfigurowanie Wartość domyślna Wartości
ForcedLegacyMode fałsz W starszych wersjach programu Visual Studio adapter MSTest został zoptymalizowany pod kątem szybszego i bardziej skalowalnego. Niektóre zachowania, na przykład kolejność, w jakiej są uruchamiane testy, mogą nie być dokładnie takie same, jak w poprzednich wersjach programu Visual Studio. Ustaw wartość true , aby używać starszej karty testowej.

Możesz na przykład użyć tego ustawienia, jeśli masz plik app.config określony dla testu jednostkowego.

Zaleca się, aby rozważyć refaktoryzację testów pozwalającą na użycie nowszego adaptera.
Plik ustawień W tym miejscu możesz określić plik ustawień testowych do użycia z adapterem MSTest. Możesz również określić plik ustawień testu z menu ustawień.

Jeśli określisz tę wartość, musisz również ustawić wartość ForcedLegacyMode na true.

<ForcedLegacyMode>true</ForcedLegacyMode>
WdrożenieEnabled prawda Jeśli ustawisz wartość false, elementy wdrożenia określone w metodzie testowej nie zostaną skopiowane do katalogu wdrożenia.
CaptureTraceOutput prawda Przechwyć wiadomości tekstowe pochodzące z Console.Write*interfejsu API , Trace.Write*Debug.Write* które będą skojarzone z bieżącym uruchomionym testem.
EnableBaseClassTestMethodsFromOtherAssemblies prawda Wartość wskazująca, czy włączyć odnajdywanie metod testowych z klas bazowych w innym zestawie niż dziedzicząca klasa testowa.
ClassCleanupLifecycle EndOfClass Jeśli chcesz, aby oczyszczanie klasy było wykonywane na końcu zestawu, ustaw go na EndOfAssembly. (Nieobsługiwane już od msTest w wersji 4 jako EndOfClass jest ustawieniem domyślnym i tylko Zachowanie klasyCleanup )
MapNotRunnableToFailed prawda Wartość wskazująca, czy wynik niemożliwy do uruchomienia jest mapowany na test, który zakończył się niepowodzeniem.
Parallelize Służy do ustawiania ustawień przetwarzania równoległego:

Procesy robocze: liczba wątków/procesów roboczych, które mają być używane do przetwarzania równoległego, czyli domyślnie liczba procesorów na bieżącym komputerze.

ZAKRES: Zakres przetwarzania równoległego. Można ustawić ją na MethodLevel. Domyślnie jest to KlasaLevel.

<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>
TestTimeout 0 Pobiera określony globalny limit czasu przypadku testowego.
TreatDiscoveryWarningsAsErrors fałsz Aby zgłosić ostrzeżenia dotyczące odnajdywania testów jako błędy, ustaw tę wartość na true.
TreatClassAndAssemblyCleanupWarningsAsErrors fałsz Aby zobaczyć błędy w czyszczeniu klas jako błędy, ustaw tę wartość na true.
DeployTestSourceDependencies prawda Wartość wskazująca, czy odwołania do źródła testów mają zostać wdrożone.
DeleteDeploymentDirectoryAfterTestRunIsComplete prawda Aby zachować katalog wdrożenia po uruchomieniu testu, ustaw tę wartość na false.
MapInconclusiveToFailed fałsz Jeśli test zakończy się z niejednoznacznym stanem, zostanie on zamapowany na stan pominięty w Eksploratorze testów. Jeśli chcesz, aby niejednoznaczne testy zostały pokazane jako nieudane, ustaw wartość true.
ConsiderFixturesAsSpecialTests fałsz Aby wyświetlić AssemblyInitializewartości , , AssemblyCleanupClassInitializeClassCleanup jako pojedyncze wpisy w programie Visual Studio i programie Visual Studio Code Test Explorer oraz .trx dzienniku, ustaw tę wartość na true
AssemblyResolution fałsz Ścieżki do dodatkowych zestawów można określić podczas znajdowania i uruchamiania testów jednostkowych. Na przykład użyj tych ścieżek dla zestawów zależności, które nie należą do tego samego katalogu co zestaw testowy. Aby określić ścieżkę, użyj elementu Ścieżka katalogu. Ścieżki mogą zawierać zmienne środowiskowe.

<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>

Należy pamiętać, że ta funkcja jest stosowana tylko w przypadku korzystania z elementu docelowego programu .NET Framework.

Przykładowy plik .runsettings

Poniższy kod XML przedstawia zawartość typowego pliku .runsettings . Skopiuj ten kod i zmodyfikuj go zgodnie z potrzebami.

Każdy element pliku jest opcjonalny, ponieważ ma wartość domyślną.

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <!-- Configurations that affect the Test Framework -->
  <RunConfiguration>
    <!-- Use 0 for maximum process-level parallelization. This does not force parallelization within the test DLL (on the thread-level). You can also change it from the Test menu; choose "Run tests in parallel". Unchecked = 1 (only 1), checked = 0 (max). -->
    <MaxCpuCount>1</MaxCpuCount>
    <!-- Path relative to directory that contains .runsettings file-->
    <ResultsDirectory>.\TestResults</ResultsDirectory>

    <!-- Omit the whole tag for auto-detection. -->
    <!-- [x86] or x64, ARM, ARM64, s390x  -->
    <!-- You can also change it from the Test menu; choose "Processor Architecture for AnyCPU Projects" -->
    <TargetPlatform>x86</TargetPlatform>

    <!-- Any TargetFramework moniker or omit the whole tag for auto-detection. -->
    <!-- net48, [net40], net6.0, net5.0, netcoreapp3.1, uap10.0 etc. -->
    <TargetFrameworkVersion>net40</TargetFrameworkVersion>

    <!-- Path to Test Adapters -->
    <TestAdaptersPaths>%SystemDrive%\Temp\foo;%SystemDrive%\Temp\bar</TestAdaptersPaths>

    <!-- TestCaseFilter expression -->
    <TestCaseFilter>(TestCategory != Integration) &amp; (TestCategory != UnfinishedFeature)</TestCaseFilter>

    <!-- TestSessionTimeout was introduced in Visual Studio 2017 version 15.5 -->
    <!-- Specify timeout in milliseconds. A valid value should be greater than 0 -->
    <TestSessionTimeout>10000</TestSessionTimeout>

    <!-- true or false -->
    <!-- Value that specifies the exit code when no tests are discovered -->
    <TreatNoTestsAsError>true</TreatNoTestsAsError>
  </RunConfiguration>

  <!-- Configurations for data collectors -->
  <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>
            <ModulePaths>
              <Exclude>
                <ModulePath>.*CPPUnitTestFramework.*</ModulePath>
              </Exclude>
            </ModulePaths>

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

          </CodeCoverage>
        </Configuration>
      </DataCollector>

      <DataCollector uri="datacollector://microsoft/VideoRecorder/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder.VideoRecorderDataCollector, Microsoft.VisualStudio.TestTools.DataCollection.VideoRecorder, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Screen and Voice Recorder">
        <!--Video data collector was introduced in Visual Studio 2017 version 15.5 -->
        <Configuration>
          <!-- Set "sendRecordedMediaForPassedTestCase" to "false" to add video attachments to failed tests only -->
          <MediaRecorder sendRecordedMediaForPassedTestCase="true"  xmlns="">           ​
            <ScreenCaptureVideo bitRate="512" frameRate="2" quality="20" />​
          </MediaRecorder>​
        </Configuration>
      </DataCollector>

      <!-- Configuration for blame data collector -->
      <DataCollector friendlyName="blame" enabled="True">
      </DataCollector>

    </DataCollectors>
  </DataCollectionRunSettings>

  <!-- Parameters used by tests at run time -->
  <TestRunParameters>
    <Parameter name="webAppUrl" value="http://localhost" />
    <Parameter name="webAppUserName" value="Admin" />
    <Parameter name="webAppPassword" value="Password" />
  </TestRunParameters>

  <!-- Configuration for loggers -->
  <LoggerRunSettings>
    <Loggers>
      <Logger friendlyName="console" enabled="True">
        <Configuration>
            <Verbosity>quiet</Verbosity>
        </Configuration>
      </Logger>
      <Logger friendlyName="trx" enabled="True">
        <Configuration>
          <LogFileName>foo.trx</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="html" enabled="True">
        <Configuration>
          <LogFileName>foo.html</LogFileName>
        </Configuration>
      </Logger>
      <Logger friendlyName="blame" enabled="True" />
    </Loggers>
  </LoggerRunSettings>

  <!-- Adapter Specific sections -->

  <!-- MSTest adapter -->
  <MSTest>
    <MapInconclusiveToFailed>True</MapInconclusiveToFailed>
    <CaptureTraceOutput>false</CaptureTraceOutput>
    <DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
    <DeploymentEnabled>False</DeploymentEnabled>
    <AssemblyResolution>
      <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
    </AssemblyResolution>
  </MSTest>

</RunSettings>

Określanie zmiennych środowiskowych w pliku .runsettings

Zmienne środowiskowe można ustawić w pliku .runsettings , który może bezpośrednio współdziałać z hostem testowym. Określenie zmiennych środowiskowych w pliku .runsettings jest niezbędne do obsługi projektów nietrivial, które wymagają ustawienia zmiennych środowiskowych, takich jak DOTNET_ROOT. Te zmienne są ustawiane podczas procesu hosta testowego i są dostępne na hoście.

Przykład

Poniższy kod to przykładowy plik runsettings , który przekazuje zmienne środowiskowe:

<?xml version="1.0" encoding="utf-8"?>
<!-- File name extension must be .runsettings -->
<RunSettings>
  <RunConfiguration>
    <EnvironmentVariables>
      <!-- List of environment variables we want to set-->
      <DOTNET_ROOT>C:\ProgramFiles\dotnet</DOTNET_ROOT>
      <SDK_PATH>C:\Codebase\Sdk</SDK_PATH>
    </EnvironmentVariables>
  </RunConfiguration>
</RunSettings>

Węzeł RunConfiguration powinien zawierać węzeł EnvironmentVariables . Zmienną środowiskową można określić jako nazwę elementu i jego wartość.

Uwaga

Ponieważ te zmienne środowiskowe powinny być zawsze ustawiane podczas uruchamiania hosta testowego, testy powinny być zawsze uruchamiane w osobnym procesie. W tym celu flaga /InIsolation zostanie ustawiona, gdy istnieją zmienne środowiskowe, tak aby host testowy był zawsze wywoływany.