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
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.
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óry chcesz użyć jednej z następujących metod:
- Visual Studio IDE
- 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 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 ustawień uruchamiania
- Ręczne ustawianie ustawień uruchamiania
- Ustawianie właściwości kompilacji
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
Wybierz pozycję Testuj>konfigurowanie uruchamiania Ustawienia> Auto Detect runsettings Files
Ręczne wybieranie pliku ustawień uruchamiania
W środowisku IDE wybierz pozycję Testuj>skonfiguruj uruchamianie Ustawienia> Wybierz plik runsettings rozwiązania Wide runsettings, 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.
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ść Run Ustawienia FilePath.
- 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ę Wybierz plik Ustawienia. Przejdź do pliku .runsettings i wybierz go.
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 /Ustawienia parametru.
Otwórz wiersz polecenia dla deweloperów dla programu Visual Studio.
Wprowadź polecenie podobne do:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingslub
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 Run Ustawienia. 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) & (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. 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.
LoggerRun Ustawienia, 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>
<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. |
| Ustawienia File | 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. |
| 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) & (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.
Powiązana zawartość
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla