Поделиться через

Обзор Microsoft.Testing.Platform

  • Статья

Microsoft.Testing.Platform — это упрощенная и переносимая альтернатива VSTest для выполнения тестов во всех контекстах, включая конвейеры непрерывной интеграции (CI), CLI, обозреватель тестов Visual Studio и текстовый обозреватель VS Code. Платформа Microsoft.Testing.Platform внедрена непосредственно в тестовые проекты и не существует других зависимостей приложений, таких как vstest.console или dotnet test, необходимых для выполнения тестов.

Microsoft.Testing.Platform является открытым исходным кодом. Код Microsoft.Testing.Platform можно найти в репозитории microsoft/testfx GitHub.

Основные принципы Microsoft.Testing.Platform

Эта новая платформа тестирования основана на опыте команды .NET Developer Experience Testing и направлена на решение проблем, возникающих с момента выпуска .NET Core в 2016 году. Хотя существует высокий уровень совместимости между .NET Framework и .NET Core/.NET, некоторые ключевые функции, такие как система плагинов и новые возможные форматы компиляций .NET, затруднили развитие или полную поддержку новой функции рантайма в рамках текущей архитектуры платформы VSTest.

Основные движущие факторы для развития новой платформы тестирования подробно описаны следующим образом.

  • детерминированность. Обеспечение того, что выполнение одних и того же теста в разных контекстах (local, CI) приведет к тому же результату. Новая среда выполнения не зависит от отражения или других динамических функций среды выполнения .NET для координации тестового выполнения.

  • прозрачность среды выполнения: Среда выполнения тестирования не вмешивается в код платформы тестирования, она не создает изолированные контексты, такие как AppDomain или AssemblyLoadContext, и не использует рефлексию или пользовательские средства разрешения сборок.

  • Регистрация расширений во время компиляции: расширения, такие как тестовые фреймворки и внутр- и внепроцессные расширения, регистрируются во время компиляции, чтобы обеспечить детерминизм и упростить обнаружение несоответствий.

  • Ноль зависимостей: Ядро платформы — это одна сборка .NET, Microsoft.Testing.Platform.dll, которая не имеет зависимостей, кроме поддерживаемых сред выполнения.

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

  • поддержка всех форм-факторов .NET: поддержка текущих и будущих форм-факторов .NET, включая Native AOT.

  • Производительность: поиск правильного баланса между функциями и точками расширения, чтобы избежать раздувания среды выполнения с использованием несущественного кода. Новая тестовая платформа предназначена для "оркестрации" тестового запуска, а не предоставления сведений о реализации о том, как это сделать.

  • Достаточно расширяемая: новая платформа построена на принципах расширяемости, чтобы обеспечить максимальную настройку выполнения в рабочем окружении. Он позволяет настроить узел тестового процесса, наблюдать за процессом тестирования и использовать сведения из платформы тестирования в процессе узла тестирования.

  • развертывание одного модуля. Функция хостинга позволяет использовать модель развертывания одного модуля, при которой один результат компиляции может поддерживать все точки расширяемости, как в режиме вне процесса, так и в режиме внутри процесса, без необходимости поставки различных исполняемых модулей.

Поддерживаемые платформы тестирования

  • MSTest. Поддержка Microsoft.Testing.Platform в MSTest выполняется через инструмент MSTest.
  • NUnit. В NUnit поддержка Microsoft.Testing.Platform осуществляется через NUnit runner.
  • xUnit.net. В xUnit.net поддержка Microsoft.Testing.Platform выполняется с помощью xUnit.net runner.
  • TUnit: полностью построен на основе Microsoft.Testing.Platform. Для получения дополнительной информации смотрите документацию по TUnit.

Выполнение и отладка тестов

Microsoft.Testing.Platform тестовые проекты создаются как исполняемые файлы, которые можно запускать напрямую (или отлаживать). Нет дополнительных тестов, выполняемых в консоли или команде. Приложение завершает работу с ненулевым кодом выхода, если возникает ошибка, что типично для большинства исполняемых файлов. Дополнительные сведения о известных кодах выхода см. в разделе "Коды выхода Microsoft.Testing.Platform".

Совет

Вы можете игнорировать определенный код выхода с помощью параметра командной строки --ignore-exit-code.

Можно также задать параметры командной строки, которые применяются к определенному тестовом проекту в файле проекта с помощью свойства TestingPlatformCommandLineArguments MSBuild. Распространённый случай использования — это тестовые проекты, в которых все тесты игнорируются, что обычно завершается кодом выхода 8 (в тестовом сеансе не выполняется ни одного теста). В этом сценарии можно добавить следующие элементы в PropertyGroup в файле проекта:

<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>

Важный

По умолчанию Microsoft.Testing.Platform собирает данные телеметрии. Дополнительную информацию и параметры отказа см. в разделе телеметрии Microsoft.Testing.Platform .

Публикация тестового проекта с помощью dotnet publish и запуск приложения напрямую является другим способом выполнения тестов. Например, выполнение команды ./Contoso.MyTests.exe. В некоторых сценариях также возможно использование dotnet build для создания исполняемого файла, но стоит учитывать крайние случаи, такие как Native AOT.

Используйте dotnet run

Для сборки и запуска тестового проекта можно использовать команду dotnet run. Это самый простой, хотя иногда самый медленный способ выполнения тестов. Использование dotnet run удобно при редактировании и выполнении тестов локально, так как это гарантирует, что тестовый проект перестраивается при необходимости. dotnet run также автоматически находит проект в текущей папке.

dotnet run --project Contoso.MyTests

Дополнительные сведения о dotnet runсм. в dotnet run.

Использование dotnet exec

Команда dotnet exec или dotnet используется для выполнения (или запуска) уже созданного тестового проекта, это альтернатива непосредственно запуску приложения. dotnet exec требуется путь к собранной dll тестового проекта.

dotnet exec Contoso.MyTests.dll

или

dotnet Contoso.MyTests.dll

Заметка

Предоставление пути к исполняемому файлу тестового проекта (*.exe) приводит к ошибке:

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Дополнительные сведения о dotnet execсм. в разделе dotnet exec.

Используйте dotnet test

Microsoft.Testing.Platform предлагает слой совместимости с vstest.console.exe и dotnet test, обеспечивая выполнение тестов, как и раньше, при этом поддерживается новый сценарий выполнения.

dotnet test Contoso.MyTests.dll

Параметры

В приведенном ниже списке описаны только параметры платформы. Чтобы просмотреть определенные параметры, представленные каждым расширением, перейдите на страницу документации по расширению или используйте параметр --help.

  • @

    Указывает имя файла ответа. Имя файла ответа должно немедленно следовать символу @без пробела между символом @и именем файла ответа.

    Параметры в файле ответа интерпретируются так, как если бы они присутствовали в этом месте в командной строке. Каждый аргумент в файле ответа должен начинаться и заканчиваться в одной строке. Символ обратной косой черты () нельзя использовать для объединения строк. Использование файла ответа помогает выполнять очень длинные команды, которые могут превышать ограничения терминала. Файл ответа можно объединить с встроенными аргументами командной строки. Например:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s

    где filter.rsp может содержать следующее содержимое:

    --filter "A very long filter"

    Или один файл rsp можно использовать для указания времени ожидания и фильтрации следующим образом:

    ./TestExecutable.exe @"arguments.rsp"

    --filter "A very long filter"
--timeout 10s

  • --config-file

    Указывает файл testconfig.json.

  • --diagnostic

    Включает ведение журнала диагностики. Уровень журнала по умолчанию — Trace. Файл записывается в выходной каталог со следующим форматом имени log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Позволяет встроенному средству ведения журнала файлов синхронно записывать журналы. Полезно для сценариев, когда вы не хотите терять записи журнала (если процесс завершается сбоем). Это замедляет выполнение теста.

  • --diagnostic-output-directory

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

  • --diagnostic-output-fileprefix

    Префикс имени файла журнала. По умолчанию используется "log_".

  • --diagnostic-verbosity

    Определяет уровень детализации при использовании переключателя --diagnostic. Доступные значения: Trace, Debug, Information, Warning, Errorили Critical.

  • --exit-on-process-exit

    Выход из тестового процесса, если зависимый процесс завершается. Необходимо указать PID.

  • --help

    Выводит описание использования команды.

  • -ignore-exit-code

    Позволяет игнорировать некоторые коды выхода, отличные от нуля, и вместо этого возвращается как 0. Дополнительные сведения см. в разделе Игнорировать определенные коды выхода.

  • --info

    Отображает дополнительные сведения о тестовом приложении .NET, например:

    • Платформа.
    • Среда.
    • Каждый зарегистрированный поставщик командной строки, например name, version, descriptionи options.
    • Каждое зарегистрированное средство, например command, name, version, descriptionи все поставщики командной строки.

    Эта функция используется для понимания расширений, которые регистрируют один и тот же параметр командной строки или изменения доступных параметров между несколькими версиями расширения (или платформой).

  • --list-tests

    Список доступных тестов. Тесты не будут выполняться.

  • --maximum-failed-tests

    Указывает максимальное количество сбоев тестов, которые при достижении прекратят выполнение теста. Поддержка этого коммутатора требует от авторов фреймворка реализовать возможность IGracefulStopTestExecutionCapability. Код выхода при достижении этого количества сбоев теста равен 13. Дополнительные сведения см. в кодах выхода Microsoft.Testing.Platform.

    Заметка

    Эта функция доступна в Microsoft.Testing.Platform, начиная с версии 1.5.

  • --minimum-expected-tests

    Указывает минимальное количество тестов, которые должны выполняться. По умолчанию ожидается выполнение хотя бы одного теста.

  • --results-directory

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

  • --timeout

    Тайм-аут выполнения глобального теста. Принимает один аргумент в виде строки в формате <value>[h|m|s], где <value> плавает.

Интеграция MSBuild

Пакет NuGet Microsoft.Testing.Platform.MSBuild предоставляет различные интеграции для Microsoft.Testing.Platform с MSBuild:

  • Поддержка dotnet test. Для получения дополнительной информации см. в разделе интеграцию dotnet test.
  • Поддержка ProjectCapability, необходимая обозревателям тестов Visual Studio и Visual Studio Code.
  • Автоматическое создание точки входа (методMain).
  • Автоматическое создание файла конфигурации.

Заметка

Эта интеграция работает транзитивно (проект, ссылающийся на другой проект, ссылающийся на этот пакет, будет вести себя так, как если он ссылается на пакет) и может быть отключен с помощью свойства MSBuild IsTestingPlatformApplication.

См. также