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

dotnet test with Microsoft.Testing.Platform (MTP)

статья This применяется к: ✔️ .NET 10 sdk и более поздних версий

Имя

dotnet test — драйвер тестирования .NET, используемый для выполнения модульных тестов с помощью Microsoft.Testing.Platform.

Synopsis

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-restore]
    [--no-ansi]
    [--no-progress]
    [--output <VERBOSITY_LEVEL>]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [<args>...]

dotnet test -h|--help

Description

С помощью платформы тестирования Майкрософт dotnet test работает быстрее, чем с помощью VSTest. Аргументы, связанные с тестом, больше не исправлены, так как они привязаны к зарегистрированным расширениям в тестовых project. Кроме того, MTP поддерживает фильтр глоббинга при выполнении тестов. Дополнительные сведения см. в разделе Microsoft.Testing.Platform.

Предупреждение

Если Microsoft.Testing.Platform включен через global.json, dotnet test ожидает, что все тестовые проекты будут использовать Microsoft.Testing.Platform. Это ошибка, если любой из тестовых проектов использует VSTest.

Неявное восстановление

Вам не нужно выполнять команду dotnet restore, так как она выполняется неявно всеми командами, которые требуют восстановления, например dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish и dotnet pack. Чтобы отключить неявное восстановление, используйте параметр --no-restore.

Команда dotnet restore по-прежнему полезна в некоторых сценариях, где явное восстановление имеет смысл, например неустанные сборки интеграции в Azure DevOps Services или в системах сборки, которые должны явно контролировать при возникновении восстановления.

В документации по dotnet restore приведены сведения об управлении каналами NuGet.

Options

Замечание

Вы можете использовать только один из следующих вариантов: --project, --solution или --test-modules. Эти параметры нельзя объединить. Кроме того, при использовании --test-modulesнельзя указать --arch, --configuration, --framework, --osили --runtime. Эти параметры не относятся к уже созданному модулю.

  • --project <PROJECT_PATH>

    Указывает путь к файлу project для запуска (имя папки или полный путь). Если значение не задано, по умолчанию используется текущий каталог.

  • --solution <SOLUTION_PATH>

    Указывает путь к файлу решения для запуска (имя папки или полный путь). Если значение не задано, по умолчанию используется текущий каталог.

  • --test-modules <EXPRESSION>

    Фильтрует тестовые модули с помощью глоббинга файлов в .NET. Будут выполняться только тесты, принадлежащие этим тестным модулям. Дополнительные сведения и примеры использования глоббинга файлов в .NET см. в разделе File globbing.

  • --root-directory <ROOT_PATH>

    Указывает корневой каталог параметра --test-modules. Его можно использовать только с параметром --test-modules.

  • --max-parallel-test-modules <NUMBER>

    Указывает максимальное количество тестовых модулей, которые могут выполняться параллельно. Значение по умолчанию — Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Указывает файл конфигурации, используемый для тестового выполнения. Если указан относительный путь, он преобразуется в абсолютный путь на основе текущего каталога. Дополнительные сведения о параметрах файла конфигурации см. в testconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

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

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

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

  • --minimum-expected-tests <NUMBER>

    Указывает минимальное количество тестов, которые необходимо выполнить. Если фактическое количество тестов меньше указанного минимума, выполнение теста завершается ошибкой с кодом выхода 9. Дополнительные сведения о кодах выхода см. в кодах выхода Microsoft.Testing.Platform.

  • -a|--arch <ARCHITECTURE>

    Указывает целевую архитектуру. Это сокращенный синтаксис для настройки идентификатора среды выполнения (RID), где указанное значение объединяется с RID по умолчанию. Например, если на компьютере win-x64 указать --arch x86, идентификатору RID присваивается значение win-x86. При использовании этого параметра не используйте параметр -r|--runtime. Доступно с .NET 6 предварительных версий 7.

  • -c|--configuration <CONFIGURATION>

    Определяет конфигурацию сборки. По умолчанию для большинства проектов используется Debug, но можно переопределить параметры конфигурации сборки в project.

  • -f|--framework <FRAMEWORK>

    Моникер целевой платформы (TFM) целевой платформы для выполнения тестов. Целевая платформа также должна быть указана в файле project.

  • --os <OS>

    Позволяет указать целевую операционную систему. Это сокращенный синтаксис для настройки идентификатора среды выполнения (RID), где указанное значение объединяется с RID по умолчанию. Например, если на компьютере win-x64 указать --os linux, идентификатору RID присваивается значение linux-x64. При использовании этого параметра не используйте параметр -r|--runtime. Доступно с .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Целевая среда выполнения для тестирования.

    Короткая форма -r доступна начиная с пакета SDK .NET 7.

    Замечание

    Выполнение тестов для решения с глобальным RuntimeIdentifier свойством (явным образом или через --arch--runtimeили--os) не поддерживается. Задайте RuntimeIdentifier на отдельном уровне project.

  • -v|--verbosity <LEVEL>

    Задает уровень детализации команды. Допустимые значения: q[uiet], m[inimal], n[ormal], d[etailed] и diag[nostic]. Дополнительные сведения см. в разделе LoggerVerbosity.

  • --no-build

    Указывает, что тестовый project не создается перед выполнением. Он также неявно задает флаг --no-restore.

  • --no-restore

    Указывает, что неявное восстановление не выполняется при выполнении команды.

  • --no-ansi

    Отключает вывод escape-символов ANSI на экран.

  • --no-progress

    Отключает ход выполнения отчетов на экран.

  • --output <VERBOSITY_LEVEL>

    Указывает детализацию выходных данных при составлении отчетов. Допустимые значения — Normal и Detailed. Значение по умолчанию — Normal.

  • --no-launch-profile

    Не пытайтесь использовать launchSettings.json для настройки приложения. По умолчанию используется, launchSettings.json который может применять переменные среды и аргументы командной строки к тестовому исполняемому файлу.

  • --no-launch-profile-arguments

    Не используйте аргументы, commandLineArgs указанные в профиле запуска для запуска приложения.

  • --property:<NAME>=<VALUE>

    Задает одно свойство MSBuild или несколько. Укажите несколько свойств, повторив параметр:

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    Короткая форма -p может использоваться для --property. То же самое относится к /property:property=value, а его короткая форма — /p. Дополнительные сведения о доступных аргументах см. в документации dotnet msbuild.

  • -?|-h|--help

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

  • args

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

    Подсказка

    Чтобы указать дополнительные аргументы для определенных проектов, используйте свойство MSBuild TestingPlatformCommandLineArguments.

Замечание

Чтобы включить ведение журнала трассировки в файл, используйте переменную среды DOTNET_CLI_TEST_TRACEFILE, чтобы предоставить путь к файлу трассировки.

Примеры

  • Запустите тесты в project или решении в текущем каталоге:

    dotnet test

  • Запустите тесты в TestProject project:

    dotnet test --project ./TestProject/TestProject.csproj

  • Запустите тесты в решении TestProjects:

    dotnet test --solution ./TestProjects/TestProjects.sln

  • Запустите тесты с помощью TestProject.dll сборки:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

  • Запустите тесты с помощью сборки TestProject.dll с корневым каталогом:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

  • Запустите тесты в текущем каталоге с покрытием кода:

    dotnet test --coverage

  • Выполните тесты и сохраните результаты в определенном каталоге:

    dotnet test --results-directory ./TestResults

  • Запустите тесты с выходными данными диагностики в определенном каталоге:

    dotnet test --diagnostic-output-directory ./Diagnostics

  • Выполните тесты, гарантирующие выполнение не менее 10 тестов:

    dotnet test --minimum-expected-tests 10

  • Запустите тесты в TestProject project, указав аргумент -bl (двоичный журнал) для msbuild:

    dotnet test --project ./TestProject/TestProject.csproj -bl

  • Запустите тесты в TestProject project, задав для свойства MSBuild DefineConstants значение DEV:

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

См. также

  • Last updated on