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

Из этой статьи вы узнаете, как перейти из VSTest в Microsoft.Testing.Platform.

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

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

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

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

Согласие на использование Microsoft.Testing.Platform

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

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

MSTest

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

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

Замечание

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

NUnit

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

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

xUnit.net

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

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

`dotnet test`

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

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

Это важно

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

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

Начиная с пакета SDK для .NET 10, существует встроенная поддержка Microsoft.Testing.Platform. Чтобы использовать его, необходимо указать средство выполнения теста, как 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>`	Не относится к Microsoft.Testing.Platform
`--blame`	Не относится к Microsoft.Testing.Platform
`--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 для любого сборщика данных. Модель расширяемости Microsoft.Testing.Platform отличается, и такой централизованный аргумент не используется всеми сборщиками данных. С помощью Microsoft.Testing.Platform каждый сборщик данных может добавить собственный параметр командной строки. Например, запуск Microsoft CodeCoverage через VSTest может быть аналогичен следующему:

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

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

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

Это важно

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

`--filter`

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

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

xUnit.net не поддерживает тот же формат фильтра при запуске с помощью Microsoft.Testing.Platform. Необходимо выполнить миграцию из фильтра на основе 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, называется "репортером" в Microsoft.Testing.Platform. В Microsoft.Testing.Platform ведение журнала явно предназначено только для диагностики.

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

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

dotnet test --logger trx

При использовании Microsoft.Testing.Platform команда становится следующей:

dotnet test --report-trx

Это важно

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

Это важно

`--settings`

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

`vstest.console.exe`

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

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

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

Visual Studio

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

Visual Studio Code

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

Azure DevOps

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

Задача VSTest

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

Задача .NET Core CLI

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

Различия в поведении между VSTest и Microsoft.Testing.Platform

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

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

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

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

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

При использовании Microsoft.Testing.Platform эта кодировка всегда сохраняется.
Если VSTest не работает в режиме изоляции (поведение vstest.console по умолчанию), кодирование сохраняется аналогично Microsoft.Testing.Platform.
При выполнении 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-03-12

Бөлісу құралы:

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

Согласие на использование Microsoft.Testing.Platform

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 и Microsoft.Testing.Platform

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

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

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

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

`dotnet test`

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

`--collect`

`--filter`

`--logger`

`--settings`

`vstest.console.exe`