Миграция из VSTest в Microsoft. Testing.Platform (MTP)

Из этой статьи вы узнаете, как выполнить миграцию из VSTest в MTP.

В этой статье рассматриваются этапы миграции и сопоставление аргументов.

Если вам по-прежнему нужно выбрать платформу, начните с обзора платформ тестирования.

Если требуется подробное поведение режимов dotnet test , см. раздел "Тестирование с помощью dotnet test".

Если вам нужен один список параметров командной строки платформы и расширения, см. справочник по параметрам интерфейса командной строки MTP.

Согласие на использование MTP

Первым шагом в миграции является согласие на использование MTP.

Для всех тестовых фреймворков добавьте <OutputType>Exe</OutputType> ко всем тестовым проектам в решении. После этого следуйте инструкциям для конкретной платформы.

MSTest

MTP поддерживается MSTest начиная с версии 3.2.0. Однако рекомендуется обновить до последней доступной версии MSTest.

Чтобы принять участие, добавьте <EnableMSTestRunner>true</EnableMSTestRunner> под PropertyGroup в файл Directory.Build.props.

Замечание

При использовании MSTest.Sdk MTP используется по умолчанию, если <UseVSTest>true</UseVSTest> не указано.

NUnit

MTP поддерживается NUnit3TestAdapter начиная с версии 5.0.0.

Чтобы принять участие, добавьте <EnableNUnitRunner>true</EnableNUnitRunner> под PropertyGroup в файл Directory.Build.props.

xUnit.net

MTP поддерживается начиная с xunit.v3.

Чтобы принять участие, добавьте <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> под PropertyGroup в файл Directory.Build.props.

`dotnet test`

Подключение к пакету SDK для .NET 9 и более ранних версий

В пакете SDK .NET 9 и более ранних версиях отсутствует родная поддержка MTP для dotnet test. Сервис поддержки построен на инфраструктуре VSTest. Чтобы использовать это, добавьте <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> в PropertyGroup в файл Directory.Build.props.

Это важно

При запуске поддержки MTP в этом режиме необходимо добавить -- для разделения dotnet test аргументов от новых аргументов платформы. Например: dotnet test --no-build -- --list-tests.

Включение пакета SDK для .NET 10 и более поздних версий

Начиная с пакета SDK .NET 10, существует поддержка MTP native. Чтобы использовать его, необходимо указать средство выполнения теста, как Microsoft.Testing.Platform в global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Это важно

В этом режиме дополнительный -- больше не используется.

Обновление `dotnet test` вызовов

Параметры dotnet test командной строки разделены на две категории: аргументы, связанные со сборкой, и связанные с тестом аргументы.

Аргументы, связанные с сборкой, не относятся к тестовой платформе, и поэтому не нужно обновлять для новой платформы. Аргументы, связанные со сборкой, перечислены здесь:

-a|--arch <ARCHITECTURE>
--artifacts-path <ARTIFACTS_DIR>
-c|--configuration <CONFIGURATION>
-f|--framework <FRAMEWORK>
-e|--environment <NAME="VALUE">
--interactive
--no-build
--nologo
--no-restore
-o|--output <OUTPUT_DIRECTORY>
--os <OS>
-r|--runtime <RUNTIME_IDENTIFIER>
-v|--verbosity <LEVEL>

Аргументы, связанные с тестом, специфичны для VSTest, поэтому их нужно преобразовать, чтобы они соответствовали новой платформе. В следующей таблице показано сопоставление аргументов VSTest и новой платформы:

Аргумент VSTest	Новый аргумент платформы
`--test-adapter-path <ADAPTER_PATH>`	Не относится к MTP
`--blame`	Не относится к MTP
`--blame-crash`	`--crashdump` (требуется расширение аварийного дампа)
`--blame-crash-dump-type <DUMP_TYPE>`	`--crashdump-type` (требуется расширение аварийного дампа)
`--blame-crash-collect-always`	Не поддерживается
`--blame-hang`	`--hangdump` (требуется расширение дампа зависания)
`--blame-hang-dump-type <DUMP_TYPE>`	`--hangdump-type` (требуется расширение дампа зависания)
`--blame-hang-timeout <TIMESPAN>`	`--hangdump-timeout` (требуется расширение дампа зависания)
`--collect <DATA_COLLECTOR_NAME>`	Зависит от сборщика данных
`-d\\|--diag <LOG_FILE>`	`--diagnostic`
`--filter <EXPRESSION>`	Зависит от выбранной платформы тестирования
`-l\\|--logger <LOGGER>`	Зависит от логгера
`--results-directory <RESULTS_DIR>`	`--results-directory <RESULTS_DIR>`
`-s\\|--settings <SETTINGS_FILE>`	Зависит от выбранной платформы тестирования
`-t\\|--list-tests`	`--list-tests`
`-- <RunSettings arguments>`	`--test-parameter` (предоставлено VSTestBridge)

`--collect`

--collect — это общая точка расширяемости в VSTest для любого сборщика данных. Модель расширяемости MTP отличается, и такой централизованный аргумент не используется всеми сборщиками данных. При использовании MTP каждый сборщик данных может добавить собственный параметр командной строки. Например, запуск Microsoft CodeCoverage через VSTest может быть аналогичен следующему:

dotnet test --collect "Code Coverage;Format=cobertura"

При использовании MTP это становится следующим:

dotnet test --coverage --coverage-output-format cobertura

Это важно

Как описано ранее, при использовании MTP с VSTest dotnet test, необходимо добавить дополнительный -- элемент перед аргументами, предназначенными для отправки на платформу. Таким образом, это становится dotnet test -- --coverage --coverage-output-format cobertura.

`--filter`

--filter — это фильтр на основе VSTest.

MSTest и NUnit поддерживают один и тот же формат фильтра, даже если используется MTP.

xUnit.net не поддерживает тот же формат фильтра при работе с MTP. Необходимо выполнить миграцию из фильтра на основе VSTest в новую поддержку фильтра в xunit.v3, которая предоставляется с помощью следующих параметров командной строки.

xUnit.net специфичных опций:

--filter-class
--filter-not-class
--filter-method
--filter-not-method
--filter-namespace
--filter-not-namespace
--filter-trait
--filter-not-trait
--filter-query

Дополнительные сведения см. в документации по Microsoft.Testing.Platform для xUnit.net и языка фильтра запросов для xUnit.net.

`--logger`

То, что обычно называется "логгер" в VSTest, называется "репортер" в MTP. В MTP ведение журнала явно предназначено только для диагностики.

--collectАналогично, --logger является общей точкой расширяемости в VSTest для любого логгера (или, в контексте MTP, любого репортера). Каждый репортер MTP может добавить свой собственный параметр командной строки, и таким образом отсутствует централизованный параметр командной строки, например VSTest --logger.

Одним из наиболее часто используемых средств ведения журнала VSTest является средство ведения журнала TRX. Этот логгер обычно вызывается следующим образом:

dotnet test --logger trx

С помощью MTP команда становится:

dotnet test --report-trx

Это важно

Для использования --report-trx необходимо установить пакет NuGet Microsoft.Testing.Extensions.TrxReport.

Это важно

Как описано ранее, при использовании MTP с VSTest dotnet test необходимы дополнительные -- данные для обработки аргументов, предназначенных для передачи платформе. Таким образом, это становится dotnet test -- --report-trx.

`--settings`

VSTest --settings используется для указания файла RunSettings для тестового запуска. RunSettings не поддерживается ядром MTP и заменен более современным testconfig.json файлом конфигурации. Однако MSTest и NUnit по-прежнему поддерживают старые RunSettings при запуске MTP, и --settings тоже по-прежнему поддерживается.

`vstest.console.exe`

Если вы используете vstest.console.exe непосредственно, рекомендуется заменить его командой dotnet test .

Обозреватель тестов

При использовании Visual Studio или обозревателя тестов Visual Studio Code может потребоваться включить поддержку MTP.

Visual Studio

Visual Studio обозреватель тестов поддерживает MTP начиная с версии 17.14. Если вы используете более раннюю версию, может потребоваться обновить Visual Studio до последней версии.

Visual Studio Code

Visual Studio Code с C# DevKit поддерживает MTP.

Azure DevOps

При использовании Azure DevOps задач может потребоваться обновить конвейер для использования MTP в зависимости от используемой задачи.

Задача VSTest

Если вы используете задачу VSTest в Azure DevOps, ее можно заменить задачей .NET Core.

Задача .NET Core CLI

Если у вас были переданы пользовательские arguments для задачи, следуйте тем же рекомендациям по dotnet test миграции.
Если вы используете задачу DotNetCoreCLI без использования собственного интерфейса MTP для .NET 10 SDK и более поздних версий с помощью файла global.json, необходимо задать задачу arguments, чтобы правильно указать каталог результатов, который он использовал для указания, а также запрошенный отчет TRX. Рассмотрим пример.
```
- task: DotNetCoreCLI@2
  displayName: Run unit tests
  inputs:
    command: 'test'
    arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
```

Поведенческие различия между VSTest и MTP

Выполнение нулевых тестов

Если тестовая сборка не выполнила ни одного теста, VSTest принимает это и завершает работу успешно. Однако MTP завершает работу с кодом выхода 8. Существует несколько способов обойти эту проблему:

Передайте --ignore-exit-code 8, когда запускаете тесты.
Если вы хотите игнорировать этот код выхода для определенного тестового проекта, добавьте следующее в файл проекта:
```
<PropertyGroup>
  <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
</PropertyGroup>
```
TESTINGPLATFORM_EXITCODE_IGNORE Используйте переменную среды.

Сохранение Console.InputEncoding

Если вы запускаете тесты в консоли, где кодовая страница была явно изменена (например, в Azure DevOps кодовая страница имеет значение 65001, соответствующее UTF8), поведение может отличаться от VSTest и MTP.

При использовании MTP эта кодировка всегда сохраняется.
Когда VSTest не работает в режиме изоляции (это поведение по умолчанию для vstest.console), кодировка сохраняется, аналогично MTP.
При выполнении VSTest в режиме изоляции (поведение dotnet testпо умолчанию), кодирование не сохраняется в тестовом узле, который выполняет тесты.

Подсказка

Причина, по которой кодировка не сохраняется в режиме изоляции VSTest, заключается в том, что процесс testhost запущен с CreateNoWindow = true. Поэтому он не подключен к исходной консоли.

Если у вас есть тест, который запускает еще один дочерний процесс и перенаправляет стандартные выходные данные, вы можете столкнуться с проблемами, если применяются все указанные ниже действия.

Кодовая страница консоли имеет значение 65001 (UTF8). Это может происходить в CI, но обычно не происходит локально. Чтобы получить локальное поведение, аналогичное CI, выполните chcp 65001 перед выполнением тестов.
Дочерний процесс запускается с кодировкой, отличной от UTF8. Это может произойти и в случае, если ваш собственный тест задает CreateNoWindow = true.

Это особенно проблематично, если дочерний процесс не ожидает увидеть байт BOM UTF-8 ("Byte-Order-Mark"), который он может получить в предыдущем сценарии в .NET Framework.

Так как это различие в поведении, скорее всего, будет проблематично именно для байта BOM, решение заключается в том, чтобы задать InputEncoding при инициализации сборки в UTF8 без BOM.

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Другое решение для этого заключается в том, чтобы не использовать CreateNoWindow = true для дочерних процессов, которые перенаправляют стандартные входные данные.

Кері байланыс

Бет пайдалы болды ма?

Last updated on 2026-04-27

Миграция из VSTest в Microsoft. Testing.Platform (MTP)

Согласие на использование MTP

MSTest

NUnit

xUnit.net

dotnet test

Подключение к пакету SDK для .NET 9 и более ранних версий

Включение пакета SDK для .NET 10 и более поздних версий

Обновление dotnet test вызовов

--collect

--filter

--logger

--settings

vstest.console.exe

Обозреватель тестов

Visual Studio

Visual Studio Code

Azure DevOps

Задача VSTest

Задача .NET Core CLI

Поведенческие различия между VSTest и MTP

Выполнение нулевых тестов

Сохранение Console.InputEncoding

Кері байланыс

Қосымша ресурстар

`dotnet test`

Обновление `dotnet test` вызовов

`--collect`

`--filter`

`--logger`

`--settings`

`vstest.console.exe`