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

Artykuł
01/27/2025

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

Dodaj plik ustawień uruchamiania do rozwiązania. W Eksploratorze rozwiązań , w menu kontekstowym rozwiązania wybierz pozycję Dodaj>Nowy element, a następnie 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.
Dodaj zawartość z pliku Example *.runsettings, a następnie dostosuj ją do Twoich potrzeb zgodnie z opisem w poniższych sekcjach.
Określ plik *.runsettings, którego chcesz użyć za pomocą jednej z następujących metod:
- IDE programu Visual Studio
- Wiersz polecenia
- tworzenie przepływu pracy przy użyciu planów testów platformy Azure lub usługi Azure DevOps Server (dawniej Team Foundation Server (TFS)).
Uruchom testy jednostkowe, aby użyć niestandardowych ustawień uruchamiania.

Jeśli chcesz przełączać ustawienia niestandardowe w IDE, odznacz lub zaznacz plik w menu Test.

Napiwek

W rozwiązaniu możesz utworzyć więcej niż jeden plik .runsettings i wybrać go jako plik ustawień aktywnego 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.

automatyczne wykrywanie ustawień uruchamiania
ręcznie ustaw ustawienia uruchamiania
Ustawianie właściwości kompilacji

Automatyczne wykrywanie pliku ustawień uruchamiania

Nota

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

Aby automatycznie wykryć 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:

Wybierz pozycję Narzędzia Tools>Options>Test>Auto Detect runsettings Files
Wybierz Test>Skonfiguruj ustawienia uruchamiania>Automatyczne wykrywanie plików ustawień uruchamiania

Ręczne wybieranie pliku ustawień uruchamiania

W środowisku IDE wybierz pozycję Test>Skonfiguruj ustawienia uruchamiania,>wybierz plik ustawień dla całego 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.

wybierz menu plików runsettings dla całego rozwiązania testowego w programie Visual Studio

Ustaw właściwość 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 można 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ę Test>Wybierz plik ustawień. Przejdź do pliku .runsettings i wybierz go.

menu Wybierz plik ustawień testu w programie Visual Studio 2019

Plik pojawia się w menu Test, i możesz go wybrać lub odznaczyć. Gdy plik ustawień uruchamiania jest wybrany, stosuje się go zawsze, gdy wybierzesz Analizuj pokrycie kodu.

Określanie pliku ustawień uruchamiania z wiersza polecenia

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

Otwórz wiersz polecenia dewelopera dla programu Visual Studio.

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, który zawiera różne elementy konfiguracji w elemencie RunSettings. Sekcje, które szczegółowo opisują różne elementy. Aby zobaczyć kompletny przykład, sprawdź plik przykładowy *.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ą.

element konfiguracji uruchomienia

<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ł	Domyślny	Wartości
MaxCpuCount	1	Nazwa opcji uwzględnia wielkość liter i można ją łatwo błędnie napisać jako MaxCPUCount. To ustawienie kontroluje poziom równoległości na poziomie procesu. Użyj wartości 0, aby włączyć maksymalną równoległość na poziomie procesów. ** To ustawienie określa maksymalną liczbę testowych bibliotek DLL lub innych kontenerów testowych, które można uruchamiać równocześnie. 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 w tym samym czasie działa tylko jeden testhost. Wartość specjalna `0` umożliwia tyle hostów testowych, ile masz procesorów logicznych (na przykład 6, dla komputera z 6 rdzeniami fizycznymi bez wielowątkowości, lub 12, dla komputera z sześcioma rdzeniami fizycznymi z wielowątkowością). 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.
WersjaDocelowegoFrameworka	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 `net48`, `net472`,`net6.0`, `net5.0`, `netcoreapp3.1`, `uap10.0` lub dowolna prawidłowa pełna nazwa platformy, taka jak`.NETFramework,Version=v4.7.2` lub `.NETCoreApp,Version=v6.0.0`. W przypadku zgodności z poprzednimi wersjami `Framework35`, `Framework40`, `Framework45`, `FrameworkCore10`, `FrameworkUap10` są akceptowane, co oznacza ( odpowiednio`net35`, `net40`, `net45`, `netcoreapp1.0` i `uap10.0`). 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 `<TargetFramework>` projektu testowego (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ń element `TargetFrameworkVersion` z pliku .runsettings, aby automatycznie określić wersję platformy na podstawie skompilowanych plików binarnych. Podczas automatycznego wykrywania wszystkie docelowe platformy są ujednolicone w jedną wspólną platformę. 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 .NET Framework (w programie Visual Studio lub vstest.console.exe w wierszu polecenia dla deweloperów) wspólną platformą docelową jest net40. W przypadku uruchamiacza .NET (dotnet test + DLLs) typowy docelowy framework jest ustawiony 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`, `x64`, `ARM`, `ARM64`, `S390x`. Podczas autodetekcji, architektura bibliotek DLL AnyCPU może się różnić w zależności od uruchamialnika. 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łszywy	fałsz, prawda
TestAdaptersPaths		Co najmniej jedna ścieżka do katalogu, w którym znajdują się adaptery testowe
TestCaseFilter		Wyrażenie filtru w formacie <właściwość><operator><wartość>[\|&<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 i nowszych.
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.exei wymusza użycie testhost.dll.
TreatNoTestsAsError	fałszywy	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 (adaptery danych diagnostycznych)

Element DataCollectors określa ustawienia adapterów danych diagnostycznych. Adaptery danych diagnostycznych zbierają dodatkowe informacje o środowisku i aplikacji poddawanej testom. Każdy adapter ma ustawienia domyślne i musisz je podać tylko wtedy, gdy nie chcesz korzystać z domyślnych.

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

Moduł zbierający dane codeCoverage

Kolektor danych pokrycia kodu tworzy dziennik, które części kodu aplikacji zostały przetestowane 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>

Zbieracz danych rejestratora wideo

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 i nowszych. Przykład konfigurowania tego modułu zbierającego dane można znaleźć w pliku Example *.runsettings.

Aby dostosować dowolny inny typ adapterów danych diagnostycznych, użyj pliku ustawień testowych .

Obwinić zbierającego dane

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

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

Tryb pliku sekwencji: aby utworzyć plik z listą testów do momentu zawieszenia
Tryb zrzutu awaryjnego: aby utworzyć zrzut podczas awarii hosta testowego
Tryb tworzenia zrzutu w przypadku zawieszenia: 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):

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 publiczną właściwość TestContext do testowej klasy.

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 adaptera testowego, który uruchamia metody testowe z atrybutem TestMethodAttribute.

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

Konfiguracja	Domyślny	Wartości
ForcedLegacyMode	fałszywy	W starszych wersjach programu Visual Studio adapter MSTest został zoptymalizowany pod kątem szybszego i bardziej skalowalnego. Niektóre zachowania, takie jak kolejność uruchamiania testów, mogą nie być dokładnie takie, jak w poprzednich wersjach programu Visual Studio. Ustaw wartość na true, aby użyć starszego adaptera testowego. Możesz na przykład użyć tego ustawienia, jeśli masz plik app.config określony dla testu jednostkowego. Zalecamy rozważenie refaktoryzacji testów, aby umożliwić korzystanie z nowszego adaptera.
PlikUstawień		W tym miejscu możesz określić plik ustawień testowych do użycia z adapterem MSTest. Możesz również określić plik ustawień testowych z menu ustawień. Jeśli określisz tę wartość, musisz również ustawić ForcedLegacyMode na wartość true. `<ForcedLegacyMode>true</ForcedLegacyMode>`
WdrożenieWłączone	prawdziwy	Jeśli ustawisz wartość na false, elementy wdrożenia określone w metodzie testowej nie zostaną skopiowane do katalogu wdrożenia.
CaptureTraceOutput	prawdziwy	Przechwyć wiadomości tekstowe pochodzące z `Console.Write`, `Trace.Write`, `Debug.Write*` interfejsu API, które zostaną skojarzone z aktualnie uruchomionym testem.
EnableBaseClassTestMethodsFromOtherAssemblies	prawdziwy	Wartość wskazująca, czy włączyć odnajdywanie metod testowych z klas bazowych w innym zestawie niż dziedzicząca klasa testowa.
CyklCzyszczeniaKlasy	EndOfClass	Jeśli chcesz, aby oczyszczanie klasy było wykonywane na końcu zestawu, ustaw na EndOfAssembly. (Nieobsługiwane już od MSTest v4, ponieważ EndOfClass jest domyślnym i jedynym zachowaniem ClassCleanup)
MapNotRunnableToFailed	prawdziwy	Wartość wskazująca, czy wynik, który nie może być uruchomiony, jest przypisany do testu zakończonego niepowodzeniem.
równoległe	Służy do ustawiania ustawień przetwarzania równoległego: Worker: liczba wątków/procesów roboczych, które mają być używane do równoległości, która jest domyślnie liczbę procesorów na bieżącej maszynie. zakres: zakres równoległego przetwarzania. Można ustawić go na MethodLevel. Domyślnie jest to ClassLevel. `<Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize>`
TestTimeout	0	Pobiera określony globalny czas zakończenia dla przypadku testowego.
TreatDiscoveryWarningsAsErrors	fałszywy	Aby zgłosić ostrzeżenia dotyczące odnajdywania testów jako błędy, ustaw tę wartość na wartość true.
TreatClassAndAssemblyCleanupWarningsAsErrors	fałszywy	Aby traktować niepowodzenia w czyszczeniu klas jako błędy, ustaw tę wartość na true.
DeployTestSourceDependencies	prawdziwy	Wartość wskazująca, czy odwołania do źródła testów mają zostać wdrożone.
UsuńKatalogWdrożeniowyPoZakończeniuTestu	prawdziwy	Aby zachować katalog wdrożenia po uruchomieniu testu, ustaw tę wartość na wartość false.
MapInconclusiveToFailed	fałszywy	Jeśli test zakończy się statusem niejednoznacznym, zostanie przypisany do statusu pominięty w Eksploratorze testów . Jeśli chcesz, aby niejednoznaczne testy zostały pokazane jako nieudane, ustaw wartość na true.
ConsiderFixturesAsSpecialTests	fałszywy	Aby wyświetlić `AssemblyInitialize`, `AssemblyCleanup`, `ClassInitialize`, `ClassCleanup` jako pojedyncze wpisy w programach Visual Studio i Visual Studio Code `Test Explorer` i dzienniku `.trx`, ustaw tę wartość na wartość true
UchwałaZgromadzenia	fałszywy	Ś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żki 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 podczas korzystania z platformy .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 złożonych projektów, które wymagają definiowania zmiennych środowiskowych, takich jak DOTNET_ROOT. Te zmienne są ustawiane podczas tworzenia 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ść.

Notatka

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.

Konfigurowanie przebiegu testowego
Dostosuj analizę pokrycia kodu
Zadanie testowe Visual Studio (Plany testowe platformy Azure)

Udostępnij za pośrednictwem

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

Tworzenie pliku ustawień uruchamiania i dostosowywanie go

Określanie pliku ustawień uruchamiania w środowisku IDE

Program Visual Studio 2019 w wersji 16.4 lub nowszej

Automatyczne wykrywanie pliku ustawień uruchamiania

Ręczne wybieranie pliku ustawień uruchamiania

Ustaw właściwość kompilacji

Program Visual Studio 2019 w wersji 16.3 lub starszej

Określanie pliku ustawień uruchamiania z wiersza polecenia

Plik *.runsettings

element konfiguracji uruchomienia

Element DataCollectors (adaptery danych diagnostycznych)

Moduł zbierający dane codeCoverage

Zbieracz danych rejestratora wideo

Obwinić zbierającego dane

TestRunParameters

LoggerRunSettings, element

MSTest element

Przykładowy plik .runsettings

Określanie zmiennych środowiskowych w pliku .runsettings

Przykład

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

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

Tworzenie pliku ustawień uruchamiania i dostosowywanie go

Określanie pliku ustawień uruchamiania w środowisku IDE

Program Visual Studio 2019 w wersji 16.4 lub nowszej

Automatyczne wykrywanie pliku ustawień uruchamiania

Ręczne wybieranie pliku ustawień uruchamiania

Ustaw właściwość kompilacji

Program Visual Studio 2019 w wersji 16.3 lub starszej

Określanie pliku ustawień uruchamiania z wiersza polecenia

Plik *.runsettings

element konfiguracji uruchomienia

Element DataCollectors (adaptery danych diagnostycznych)

Moduł zbierający dane codeCoverage

Zbieracz danych rejestratora wideo

Obwinić zbierającego dane

TestRunParameters

LoggerRunSettings, element

MSTest element

Przykładowy plik .runsettings

Określanie zmiennych środowiskowych w pliku .runsettings

Przykład

Powiązana zawartość

Opinia

Dodatkowe zasoby