Настройка модульных тестов с помощью файла .runsettings
Файл runettings можно использовать для настройки запуска модульных тестов. Например, его можно использовать для изменения версии .NET, в которой выполняются тесты, каталога для результатов теста или данных, собранных во время тестового выполнения. Чаще всего файл .runsettings используют для настройки анализа объема протестированного кода.
Файлы Runettings можно использовать для настройки тестов, выполняемых из командной строки, из интегрированной среды разработки или в рабочем процессе сборки с помощью планов тестирования Azure или Сервера Azure DevOps (ранее известного как Team Foundation Server (TFS)).
Файлы runsettings являются необязательными. Если вам не требуется специальная конфигурация, файл .runsettings не нужен.
Создание и настройка файла параметров запуска
Добавьте файл параметров запуска в решение. В обозревателе решений в контекстном меню выберите Добавить>Новый элемент и XML-файл. Сохраните файл с именем, похожим на test.runsettings.
Если вы не видите все шаблоны элементов, выберите "Показать все шаблоны" и выберите шаблон элемента.
Совет
Имя файла не имеет значения, если вы используете расширение .runsettings.
Добавьте содержимое из примера файла *.runsettings, а затем настройте его в соответствии с собственными требованиями, как описано в следующих разделах.
Указать нужный файл *.runsettings можно с помощью одного из следующих методов:
- Интегрированная среда разработки Visual Studio
- Командная строка
- Создание рабочего процесса с помощью планов тестирования Azure или Сервера Azure DevOps (прежнее название — Team Foundation Server (TFS)).
Выполните модульные тесты с применением пользовательских параметров запуска.
Чтобы включить или отключить пользовательские параметры в интегрированной среде разработки, выберите файл или отмените его выбор в меню Тест.
Совет
Можно создать в решении несколько файлов .runsettings файлов и при необходимости выбирать один из них в качестве действующего файла параметров тестирования.
Указание файла параметров запуска в интегрированной среде разработки
Доступные методы зависят от используемой версии среды Visual Studio.
Visual Studio 2019 версии 16.4 и более поздней
Файл параметров запуска можно указать в Visual Studio 2019 версии 16.4 или более поздней тремя способами:
- автоматическое определение параметров запуска;
- настройка параметров запуска вручную;
- задание свойства сборки.
Автоматическое определение параметров запуска
Примечание.
Оно будет работать только для файла с именем .runsettings.
Чтобы файл параметров запуска определялся автоматически, поместите его в корень решения.
Если включено автоматическое определение файлов параметров запуска, параметры в этом файле применяются ко всем тестовым запускам. Вы можете включить автоматическое обнаружение RUNSETTINGS-файлов двумя способами.
Выберите Сервис>Параметры>Тест>Автоматическое обнаружение файлов параметров выполнения
Выберите Тест>Настройка параметров выполнения>Автоматическое обнаружение файлов параметров выполнения
Выбор файла параметров запуска вручную
В интегрированной среде разработки выберите Тест>Настройка параметров выполнения>Выберите файл параметров выполнения на уровне решения, а затем выберите файл с расширением RUNSETTINGS.
- Этот файл переопределяет RUNSETTINGS-файл в корневом каталоге решения, если он существует, и применяется ко всем тестовым запускам.
- Этот выбор файла сохраняется только локально.
Задание свойства сборки
Добавить свойство сборки в проект с помощью файла проекта или файла Directory.Build.props. Файл параметров запуска для проекта задается свойством RunSettingsFilePath.
- В настоящее время параметры запуска на уровне проекта поддерживаются в проектах C#, VB, C++ и F#.
- Файл, указанный для проекта, переопределяет любой другой файл параметров запуска, указанный в решении.
- Эти свойства MSBuild можно использовать для указания пути к файлу параметров запуска.
Пример указания файла с расширением RUNSETTINGS для проекта:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<RunSettingsFilePath>$(MSBuildProjectDirectory)\example.runsettings</RunSettingsFilePath>
</PropertyGroup>
...
</Project>
Visual Studio 2019 версии 16.3 и более ранней
Чтобы указать файл параметров запуска в интегрированной среде разработки, выберите Тестирование>Выбрать файл параметров. Найдите и выберите файл .runsettings.
В меню "Тестирование" появится файл, который можно выбрать или отменить выбор. Если файл параметров запуска выбран, он применяется при каждом выборе функции Анализ объема протестированного кода.
Указание файла параметров тестирования в командной строке
Для запуска тестов из командной строки используйте vstest.console.exe и укажите файл параметров с помощью параметра /Settings.
Введите команду, подобную следующей:
vstest.console.exe MyTestAssembly.dll /EnableCodeCoverage /Settings:CodeCoverage.runsettingsor
vstest.console.exe --settings:test.runsettings test.dll
Дополнительные сведения см. в статье Параметры командной строки для VSTest.Console.exe.
RUNSETTINGS-файл
Файл RUNSETTINGS — это XML-файл, который содержит различные элементы конфигурации в элементе RunSettings. В последующих разделах подробно описаны эти элементы. Полный пример см. в образце файла *.runsettings.
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<!-- configuration elements -->
</RunSettings>
Каждый элемент конфигурации необязателен, так как имеет значение по умолчанию.
Элемент RunConfiguration
<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>
Элемент RunConfiguration может содержать следующие элементы:
| Узел | По умолчанию. | Values |
|---|---|---|
| MaxCpuCount | 1 | Имя параметра чувствительно к регистру, и легко неправильно написать его как MaxCPUCount. Этот параметр управляет степенью параллелизма на уровне процесса. Чтобы задать максимальную степень параллелизма на уровне процесса, используйте значение 0. Этот параметр определяет максимальное количество тестовых библиотек DLL или других тестовых контейнеров, которые могут выполняться параллельно. Каждая библиотека DLL выполняется в собственном процессе testhost и изолирована на уровне процесса от тестов в других тестовых библиотеках DLL. Этот параметр не заставляет тесты в каждой тестовой библиотеке DLL выполняться параллельно. Управление параллельным выполнением в библиотеке DLL (на уровне потока) осуществляется в среде тестирования, такой как MSTest, XUnit или NUnit. Значение по умолчанию — это 1означает, что одновременно выполняется только один testhost. Специальное значение 0 позволяет использовать столько тестовых узлов, сколько у вас есть логические процессоры (например, 6, для компьютера с 6 физическими ядрами без многопотокового или 12 для компьютера с шестью физическими ядрами с несколькими потоками).Количество отдельных библиотек DLL в выполнении определяет фактическое количество запущенных тестовых узлов. |
| ResultsDirectory | Каталог для сохранения результатов тестов. Путь задается относительно каталога, содержащего файл RUNSETTINGS. | |
| TargetFrameworkVersion | net40 или netcoreapp1.0 | Опустите этот тег целиком для автоматического обнаружения. Этот параметр определяет версию или семейство платформы, используемой для выполнения тестов. Допустимые значения — это любой моникер платформы, например net48, net472,net6.0, net5.0, netcoreapp3.1, uap10.0 или любое допустимое полное имя платформы, например .NETFramework,Version=v4.7.2 или .NETCoreApp,Version=v6.0.0. Для обеспечения обратной совместимости принимаются значения Framework35, Framework40, Framework45, FrameworkCore10, FrameworkUap10, то есть (net35, net40, net45, netcoreapp1.0 и uap10.0 соответственно). Все значения указываются без учета регистра.Указанное значение используется для определения используемого поставщика среды выполнения тестирования. Каждый поставщик среды выполнения тестирования должен учитывать семейство платформы для использования, но может не учитывать точную версию платформы: Для платформы .NET Framework 4.5.1–4.8 используется процесс testhost, собранный с использованием указанной точной версии. Для значений за пределами этого диапазона используется процесс testhost платформы .NET Framework 4.5.1. Для .NET тестовый проект <TargetFramework> (или более runtimeconfig.jsonточно) определяет фактическую версию.Для универсальной платформы Windows приложение тестового проекта является процессом testhost само по себе и определяет фактическую версию используемой универсальной платформы Windows. Пропустите элемент TargetFrameworkVersion из файла .runsettings, чтобы автоматически определить версию платформы из созданных двоичных файлов.При автоматическом определении все целевые платформы объединяются в одну общую платформу. При обнаружении другой версии из одного семейства целевой платформы выбирается более новая версия (например, net452, net472, net48 = net48). Для средства выполнения платформы .NET Framework (в Visual Studio или vstest.console.exe в командной строке разработчика) для общей целевой платформы задано значение net40. Для средства выполнения .NET (dotnet test + библиотеки DLL) для общей целевой платформы задано значение netcoreapp1.0. |
| TargetPlatform | x86 | Опустите этот тег целиком для автоматического обнаружения. Этот параметр определяет архитектуру, используемую для выполнения тестов. Возможные значения: x86, x64, ARM, ARM64, S390x.При автоматическом определении архитектура библиотек DLL AnyCPU может отличаться на основе средства выполнения. Для средства выполнения платформы .NET Framework (в Visual Studio или vstest.console.exe в командной строке разработчика) значение по умолчанию — x86. Для средства выполнения .NET (dotnet test) по умолчанию используется архитектура текущего процесса. |
| TreatTestAdapterErrorsAsWarnings | false | false, true |
| TestAdaptersPaths | Один или несколько путей к каталогу, где находятся адаптеры TestAdapters | |
| TestCaseFilter | Выражение фильтра в значении> оператора><свойства><форматирования<[|&<Выражение>]. Логический оператор и должен быть представлен html-сущностью &. Выражения можно заключать в круглые скобки. Подробный синтаксис структуры выражений см. в разделе vstest/docs/filter.md. | |
| TestSessionTimeout | Дает пользователям возможность завершить сеанс тестирования, если его длительность превышает заданный промежуток времени. Задав время ожидания, вы обеспечите надлежащее использование ресурсов и ограничите выполнение сеансов тестирования определенным периодом. Этот параметр доступен в Visual Studio 2017 версии 15.5 и более поздних версий. | |
| DotnetHostPath | Укажите пользовательский путь к узлу dotnet, который используется для запуска testhost. Это полезно при создании собственной dotnet, например при создании репозитория dotnet/runtime. Указание этого параметра пропускает поиск testhost.exe и принудительно использует testhost.dll. | |
| TreatNoTestsAsError | false | true или false Укажите логическое значение, определяющее код выхода, если тесты не обнаружены. Если значение не true обнаружено и не обнаружены тесты, возвращается ненулевой код выхода. В противном случае возвращается ноль. |
Элемент DataCollectors (адаптеры диагностических данных)
Элемент DataCollectors задает параметры адаптеров диагностических данных. Адаптеры диагностических данных собирают дополнительные сведения о среде и тестируемом приложении. Для каждого адаптера заданы параметры по умолчанию; указывать параметры следует, только если вы не хотите использовать параметры по умолчанию.
<DataCollectionRunSettings>
<DataCollectors>
<!-- data collectors -->
</DataCollectors>
</DataCollectionRunSettings>
Сборщик данных CodeCoverage
Сборщик данных о покрытии кода создает журнал с указанием того, какие части кода приложения были включены в тест. Подробные сведения о настройке параметров объема протестированного кода см. в разделе Настройка анализа объема протестированного кода.
<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>
Сборщик данных VideoRecorder
Сборщик видеоданных захватывает запись экрана при выполнении тестов. Эта запись полезна для устранения неполадок тестов пользовательского интерфейса. Сборщик видеоданных предусмотрен в Visual Studio 2017 версии 15.5 и более поздних версий. Пример настройки этого сборщика данных см. в образце файла *.runsettings.
Для настройки любого другого типа адаптеров диагностических данных используйте файл параметров тестирования.
Запуск cборщика данных в режиме обвинения
Этот параметр помогает изолировать проблемный тест, из-за которого в узле тестов возникает сбой. При запуске сборщика создается выходной файл (Sequence.xml) в TestResults, в который записывается порядок выполнения теста перед сбоем.
Вы можете выполнять винить в трех разных режимах:
- Режим файла последовательности: создание файла со списком тестов до зависания
- Режим аварийного дампа: создание дампа при сбое testhost
- Режим зависания дампа: чтобы создать дампа, когда тест не завершается до заданного времени ожидания
Конфигурацию XML нужно поместить непосредственно в узел <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>
Параметры тестового запуска предоставляют способ определения переменных и значений, доступных для тестов во время выполнения. Обращайтесь к параметрам с помощью свойства MSTest TestContext.Properties (или NUnit TestContext):
private string _appUrl;
public TestContext TestContext { get; set; }
[TestMethod] // [Test] for NUnit
public void HomePageTest()
{
string _appUrl = TestContext.Properties["webAppUrl"];
}
Чтобы использовать параметры тестового запуска, добавьте в тестовый класс общедоступное свойство TestContext.
Элемент LoggerRunSettings
Раздел LoggerRunSettings определяет средства ведения журнала, которые будут использоваться при тестовом запуске. Самые распространенные средства ведения журнала — это консоль, файл с результатами теста Visual Studio (TRX) и 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
Эти параметры относятся к адаптеру тестов, выполняющему методы теста, которые имеют атрибут TestMethodAttribute.
<MSTest>
<MapInconclusiveToFailed>True</MapInconclusiveToFailed>
<CaptureTraceOutput>false</CaptureTraceOutput>
<DeleteDeploymentDirectoryAfterTestRunIsComplete>False</DeleteDeploymentDirectoryAfterTestRunIsComplete>
<DeploymentEnabled>False</DeploymentEnabled>
<AssemblyResolution>
<Directory path="D:\myfolder\bin\" includeSubDirectories="false"/>
</AssemblyResolution>
</MSTest>
| Настройка | По умолчанию. | Values |
|---|---|---|
| ForcedLegacyMode | false | В более ранних версиях Visual Studio адаптер MSTest оптимизирован для ускорения и повышения масштабируемости. Некоторое поведение, в частности порядок, в котором выполняются тесты, может немного отличаться от поведения в предыдущих выпусках Visual Studio. Задайте значение true , чтобы использовать старый адаптер теста. Например, этот параметр можно использовать при наличии файла app.config, указанного для модульного теста. Рекомендуется рассмотреть возможность рефакторинга тестов для включения возможности использования более нового адаптера. |
| SettingsFile | Здесь можно задать файл параметров тестирования для использования с адаптером MSTest. Этот файл можно также указать из меню параметров. Если задано это значение, необходимо также задать для параметра ForcedlegacyMode значение true. <ForcedLegacyMode>true</ForcedLegacyMode> |
|
| DeploymentEnabled | true | Если установить для этого параметра значение false, то элементы развертывания, заданные в методе теста, не будут копироваться в каталог развертывания. |
| CaptureTraceOutput | true | Запись текстовых сообщений, поступающих из Console.Write*, Trace.Write*Debug.Write* API, которая будет связана с текущим запущенным тестом. |
| EnableBaseClassTestMethodsFromOtherAssemblies | true | Значение, указывающее, следует ли включить обнаружение методов тестирования из базовых классов в другой сборке, отличной от наследующего тестового класса. |
| ClassCleanupLifecycle | EndOfClass | Если вы хотите, чтобы очистка класса произошла в конце сборки, задайте для него значение EndOfAssembly. (Больше не поддерживается начиная с MSTest версии 4, так как EndOfClass — это значение по умолчанию и только Поведение ClassCleanup ) |
| MapNotRunnableToFailed | true | Значение, указывающее, сопоставляется ли неисправный результат с неудачным тестом. |
| Распараллелить | Используется для задания параметров параллелизации: Рабочие роли: количество потоков или рабочих ролей, используемых для параллелизации, которое по умолчанию является числом процессоров на текущем компьютере. ОБЛАСТЬ: область параллелизации. Его можно задать в MethodLevel. По умолчанию это ClassLevel. <Parallelize><Workers>32</Workers><Scope>MethodLevel</Scope></Parallelize> |
|
| TestTimeout | 0 | Возвращает указанное время ожидания глобального тестового случая. |
| TreatDiscoveryWarningsAsErrors | false | Чтобы сообщить об предупреждениях об обнаружении тестов в виде ошибок, задайте для этого значения значение true. |
| TreatClassAndAssemblyCleanupWarningsAsErrors | false | Чтобы увидеть ошибки в очистке класса в виде ошибок, задайте для этого значения значение true. |
| DeployTestSourceDependencies | true | Значение, указывающее, следует ли развертывать тестовые исходные ссылки. |
| DeleteDeploymentDirectoryAfterTestRunIsComplete | true | Чтобы сохранить каталог развертывания после завершения тестового запуска, установите для этого параметра значение false. |
| MapInconclusiveToFailed | false | Если тест завершается с неуклюзивным состоянием, он сопоставляется с пропущенным состоянием в тестовом Обозреватель. Если требуется, чтобы тесты с неопределенным результатом отображались как завершившиеся неудачно, установите для этого параметра значение true. |
| AssemblyResolution | false | При поиске и выполнении модульных тестов можно указать пути к дополнительным сборкам. Например, эти пути можно использовать для сборок зависимостей, которые не находятся в том же каталоге, что и тестовая сборка. Чтобы указать путь, используйте элемент путь к каталогу. Пути могут содержать переменные среды.<AssemblyResolution> <Directory path="D:\myfolder\bin\" includeSubDirectories="false"/> </AssemblyResolution>Обратите внимание, что эта функция применяется только при использовании целевого объекта платформа .NET Framework. |
Пример файла .runsettings
Следующий XML-код представляет содержимое обычного файла .runsettings. Скопируйте этот код и измените его в соответствии с требованиями.
Каждый элемент этого файла необязателен, так как все они имеют значения по умолчанию.
<?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>
Указание переменных среды в файле .runsettings
Вы можете задавать переменные среды в файле .runsettings, способный напрямую взаимодействовать с узлом тестов. Указание переменных среды в файле .runsettings необходимо для поддержки особых проектов, требующих установки таких переменных среды, как DOTNET_ROOT. Эти переменные задаются во время создания процесса тестового узла, и они доступны в узле.
Пример
Следующий код является примером файла .runsettings, который передает переменные среды:
<?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>
Узел RunConfiguration должен содержать узел EnvironmentVariables. Переменная среды может быть указана как имя и значение элемента.
Примечание.
Поскольку эти переменные среды должны всегда быть заданы при запуске узла тестов, тесты всегда должны выполняться в отдельном процессе. Для этого при наличии переменных среды будет устанавливаться флаг /InIsolation, позволяющий всегда вызывать узел тестов.
Связанный контент
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по