Миграция из 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 для дочерних процессов, которые перенаправляют стандартные входные данные.