dotnet test с Microsoft. Testing.Platform (MTP)

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

Имя

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

Synopsis

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--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>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Description

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

Important

Параметры, относящиеся к расширению, не встроены в MTP. Каждое целевое тестовое приложение должно зарегистрировать расширение, которое предоставляет возможность. Добавьте пакет NuGet расширения напрямую или используйте конфигурацию или профиль тестового пакета SDK, который включает этот пакет. В противном случае тестовый запуск завершается сбоем с кодом выхода 5, так как параметр не распознается. Запустите dotnet test --help , чтобы просмотреть параметры, доступные для выбранных тестовых приложений, и просмотрите параметры расширения по сценариям , чтобы найти пакет для параметра.

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

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

Требования к версии

Для режима dotnet test MTP требуется пакет SDK .NET 10 и MTP 1.7 или более поздней версии. Параметры, добавленные после .NET 10, имеют отдельные требования к версии пакета SDK в следующих разделах. Для некоторых вариантов также требуется более новый пакет MTP, так как пакет SDK координирует полный запуск, пока каждое тестовое приложение реализует соответствующую возможность.

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

Вам не нужно выполнять команду 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, --device, , --framework, --list-devices, --os--runtimeили --use-current-runtime. Эти параметры требуют оценки проекта или не относятся к уже созданному модулю.

  • PROJECT_OR_TRAVERSAL_PATH

    Указывает проект или обходный проект для запуска. Начиная с .NET 11 предварительной версии 7, dotnet test поддерживает Microsoft.Build.Traversal такие проекты, как dirs.projи рекурсивно выполняет свои тестовые проекты, на которые ссылается ссылка.

    Начиная с .NET 12 предварительной версии 1 аргумент также может определить тестовое приложение MTP на основе C#. Тестовые приложения на основе файлов не поддерживаются --device.

  • --project <PROJECT_PATH>

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

  • --solution <SOLUTION_PATH>

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

  • --test-modules <EXPRESSION>

    Фильтрует тестовые модули с помощью глобинга файлов. Выполняются только тесты, принадлежащие этим тестным модулям. Начиная с .NET 11( предварительная версия 6), префикс шаблона с ! исключением соответствующих модулей. Разделение нескольких шаблонов с запятой; пробелы вокруг каждого шаблона игнорируются.

  • --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>

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

  • --results-directory-layout <flat|per-module>

    Указывает, как запуск с несколькими модулями упорядочивает файлы в каталоге результатов. Значение по умолчанию flatзаписывает все результаты в один каталог. per-module записывает результаты каждого модуля, в который отчеты <project>/<target-framework>_<runtime-or-architecture>не будут перезаписывать друг друга.

    Доступно начиная с .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

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

  • --minimum-expected-tests <NUMBER>

    Указывает положительное минимальное количество тестов для всего выполнения. Если агрегированное число тестов меньше указанного минимума, тестовый запуск завершается с кодом выхода 9. Глобальное число включает пропущенные тесты. Дополнительные сведения о кодах выхода см. в разделе "Коды выхода MTP".

    Так как этот параметр отображается раньше --, это глобальный (весь запуск) параметр. Чтобы вместо этого требуется минимальное значение для каждого тестового модуля, передайте этот параметр после -- того, чтобы он переадресовался в каждый тестовый модуль. Дополнительные сведения см. в разделе "Минимальные значения для всего выполнения и каждого модуля".

    Замечание

    Для глобального минимума требуется пакет SDK .NET 10 (10.0.100) или более поздней версии.

  • --maximum-failed-tests <NUMBER>

    Останавливает полный запуск после достижения указанного числа неудачных, ошибок, времени ожидания или отмененных тестов. Выполнение завершает работу с кодом 13.

    Доступно начиная с .NET 11 предварительной версии 7 и требуется MTP 2.4 или более поздней версии.

  • --timeout <DURATION>

    Останавливает полный запуск после указанной длительности, пока выполняется по крайней мере одно тестовое приложение. Укажите положительное число, за которым следует единица, например 500ms, 90s, или 1d10m2h. Время ожидания завершается с кодом 3.

    Доступно начиная с .NET 11 предварительной версии 7 и требуется MTP 2.4 или более поздней версии.

  • -e|--environment <NAME="VALUE">

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

    Используйте пакет SDK .NET версии 10.0.110 или более поздней версии, если профиль запуска не существует или когда указан--no-launch-profile; более ранние версии пакета SDK .NET 10 могут игнорировать переменные в этих случаях. Начиная с .NET 11 предварительной версии 7 переменные также будут передаваться в функциональность сборки, выбора устройства, развертывания и целевых объектов запуска.

  • -a|--arch <ARCHITECTURE>

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

  • --artifacts-path <ARTIFACTS_DIR>

    Все выходные файлы сборки из выполняемой команды будут отправляться в вложенные папки в соответствии с указанным путем, разделенным проектом. Дополнительные сведения см. в макете выходных данных артефактов. Этот параметр и указанное значение должны быть явно каскадными в любой dotnet команде, которая зависит от выходных данных другой dotnet команды, например при использовании dotnet build --no-restore и dotnet publish --no-build. Доступно с .NET 8 SDK.

    Доступно для режима MTP, начиная с .NET 11.

  • -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.

  • --use-current-runtime|--ucr

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

    Доступно начиная с .NET 11 предварительной версии 6. Этот параметр нельзя объединить с --test-modules.

  • -v|--verbosity <LEVEL>

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

  • --no-build

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

  • --no-dependencies

    Пропускает сборку ссылок на проекты в проект.

    Доступно начиная с .NET 11 предварительной версии 6.

  • --no-restore

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

  • --nologo|--no-logo|--no-banner

    Подавляет баннеры запуска .NET и MTP. Поддерживаются -nologo и формы, а /nologoDOTNET_NOLOGO также переменная среды.

    Доступно в режиме MTP, начиная с .NET 11 предварительная версия 7.

  • --no-ansi

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

  • --no-progress

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

  • --no-artifact-post-processing

    Отключает после обработки совместимых артефактов после выполнения нескольких модулей. Начиная с .NET 11 RC 1 и MTP 2.4 зарегистрированные артефакты после процессоров могут объединять совместимые отчеты, такие как TRX результаты. Если после обработки завершается сбой, пакет SDK сохраняет исходные артефакты и тестовый код выхода.

  • --output <VERBOSITY_LEVEL>

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

  • --show-test-results <OUTCOME>

    Выбирает блоки результатов по результатам. В предварительной версии MTP 2.4 используйте passed, , failed, allskippedили none. Значение failed также содержит ошибки, время ожидания и отмены.

    Объединение passed, failedа также skipped запятые, пробелы или повторяющиеся --show-test-results параметры. Не сочетайте или none не с all другим значением. Этот явный --output параметр переопределяет предустановку независимо от порядка параметров.

  • --list-tests [text|json]

    Список обнаруженных тестов без их выполнения. Опустите значение или укажите text для выходных данных, доступных для чтения пользователем. Начиная с .NET 11 предварительной версии 7, укажите json для документа JSON с версией, который группирует тесты по сборке, целевой платформе и архитектуре и включает доступные идентификаторы, исходные расположения, методы, параметры и признаки.

  • --no-launch-profile

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

  • --no-launch-profile-arguments

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

  • --device <DEVICE_ID>

    Выбирает устройство, эмулятор или симулятор для каждой целевой платформы в тестовом проекте Android или iOS. Путь MTP также поддерживает тестовые проекты macOS и Mac Catalyst. Если входные данные доступны в интерактивном режиме и несколько устройств доступны, dotnet test вы можете выбрать один из них.

    Доступно начиная с .NET 11 предварительной версии 6. Для многоцеловых проектов используйте .NET 11 RC 2 или более поздней версии, чтобы обнаружение устройств правильно оценило каждую целевую платформу. Тестовые проекты браузера WebAssembly не поддерживаются этим параметром.

  • --list-devices

    Выводит список доступных устройств для проекта без выполнения тестов. Укажите проект, а не решение.

    Доступно начиная с .NET 11 предварительной версии 7.

  • --collect-test-map и --affected-tests.

    Сбор карты тестирования репозитория или выполнение тестов, затронутых изменением. Для этих экспериментальных параметров требуется отдельно распределенное расширение и DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 переменная среды. Вы не можете объединить два варианта. Рабочие процессы затронутых тестов также не поддерживают тестирование устройств, параллельные модули тестирования или политики минимального тестирования.

    Доступно начиная с .NET 11 RC 1.

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

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

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

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

  • -?|-h|--help

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

  • args

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

    Подсказка

    Чтобы указать дополнительные аргументы для определенных проектов, используйте свойство MSBuild TestingPlatformCommandLineArguments. Это свойство особенно полезно, если решение смешивает тестовые платформы (например, MSTest и xUnit.net) или когда ссылки только на определенное расширение ссылаются только на некоторые проекты. Дополнительные сведения см. в разделе "Решения с смешанными платформами тестирования" или "расширениями".

Замечание

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

Начиная с версии .NET 11 RC 1, dotnet test -bl использует один сеанс MSBuild для работы с несколькими проектами, несколькими целевыми и устройствами, поэтому двоичный журнал содержит полную сборку.

Поведение вывода и отмены

Начиная с .NET 11 предварительная версия 6, интерактивные выходные данные ANSI показывают тесты, выполняемые в настоящее время и отчеты для каждого теста сборки. Отображение хода выполнения остается отключенным, если выходные данные перенаправлены, ANSI или выходные данные хода выполнения отключены, или среда не является интерактивной.

Начиная с .NET 11 предварительной версии 6, первый CTRL+C останавливает планирование новых тестовых приложений и запрашивает совместную отмену. Нажмите клавиши CTRL+C еще раз, чтобы немедленно завершить дочерние процессы. Прерывание выполнения завершается с кодом 3.

Для выходных данных в реальном тестовом узле требуется узел MTP, поддерживающий протокол 1.1 или более поздней версии. Старые узлы сохраняют выходные данные и воспроизводит его для модуля сбоем. Начиная с .NET 11 preview 7, сводные данные обрезки записываются в стандартные выходные данные более 40 строк до первых 30 и последних 10 строк; журналы диагностики сохраняют полные выходные данные.

Для выполнения dotnet test нескольких модулей оценивается результат нулевого теста во время полного запуска, начиная с .NET 11 предварительная версия 7. Модуль без тестов не завершается ошибкой запуска, если другой модуль успешно выполняет тесты, если не требуется больше тестов явной политики минимального тестирования.

Результаты и артефакты

Если включено выходной макет артефактов пакета SDK, .NET 11 RC 1 и более поздних версий помещает отчеты MTP, файлы покрытия и диагностику <ArtifactsPath>/test/<project>/<pivot> по умолчанию. Явный --results-directory или --results-directory-layout имеет приоритет.

Начиная с .NET 11 RC 1 и MTP 2.4 совместимые расширения могут выполнять артефакты после обработки из многомодулемного запуска. Например, расширение TRX может создать объединенный отчет при сохранении отчетов для каждого модуля. Сведения о требованиях к расширению и отчетам см. в отчетах о тестах MTP.

Переадресация аргументов в тестовое приложение

dotnet test перенаправит какой-либо маркер, который он не распознает тестовому приложению. Если распознанный параметр отображается между нераспознанным именем параметра и его значением, удаление распознаваемого параметра может изменить способ привязки оставшихся маркеров к параметрам в тестовом приложении. Чтобы избежать этой неоднозначности, поместите аргументы тестового приложения после литерала --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

В предыдущем примере требуется Microsoft.Testing.Extensions.TrxReport пакет либо в виде прямой ссылки на пакет, либо с помощью конфигурации тестового пакета SDK, которая включает его.

То же поведение синтаксического анализа применяется к dotnet run и dotnet build. Подробный пример см. в разделе "Переадресация аргументов в приложение " в справочнике dotnet run .

Минимальные значения для всего выполнения и каждого модуля

Для --minimum-expected-testsэтого -- разделитель определяет область параметра:

  • Аргументы перед-- глобальными. Оркестратор dotnet test интерпретирует их для всего выполнения.
  • Аргументы после-- этого являются локальными. dotnet test перенаправит их в каждый тестовый модуль, поэтому каждый модуль применяет их независимо.

Так как --minimum-expected-tests в обоих областях доступно минимальное значение для всего выполнения, для каждого модуля или обоих модулей:

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

Предыдущая команда требует по крайней мере 5 тестов во всем выполнении и по крайней мере 2 теста в каждом модуле тестирования.

Два количества областей пропускали тесты по-разному:

Scope Количество пропущенных тестов к минимуму?
Глобальный Yes. Совокупный dotnet test итог включает пропущенные тесты.
На модуль No. MTP исключает пропущенные тесты из числа запущенных тестов.

Начиная с пакета SDK для .NET 11, вердикт нулевого теста для всего выполнения определяется один раз из агрегированных результатов. Модуль, который не соответствует тестам, например из-за --test-modules или глобального --filter, завершается с кодом 8 (ZeroTests), но этот код нормализуется до объединения результатов. В результате один пустой модуль не завершается сбоем всего выполнения, хотя модуль сохраняет свою Exit code: 8 диагностику в выходных данных для видимости.

Предоставляются --zero-tests-policy <allow-skipped|strict>MTP 4.3.0 и более поздние версии. Значение allow-skippedпо умолчанию позволяет успешно пропустить модуль. Значение strict обрабатывает пропущенные тесты как не выполняемые, поэтому все пропущенные модули завершаются кодом 8. Передайте параметр после -- переадресации в каждый тестовый модуль:

dotnet test -- --zero-tests-policy strict

Если вы не задаете глобальное минимальное значение, пакет SDK .NET 11 определяет вердикт полного выполнения ноль-тестов отдельно. Все пропущенные весь запуск завершается с кодом 8 независимо от значения каждого модуля --zero-tests-policy .

При указании --minimum-expected-tests и минимальном значении выполнение завершается сбоем с кодом выхода 9 (MinimumExpectedTestsPolicyViolation). Этот код отличается от 8, поэтому минимальный глобальный или минимальный размер для каждого модуля не путается с пустым модулем. Для минимального значения для каждого модуля для возврата кода 9 при выполнении ноль тестов модуль должен использовать MTP 4.4.0 или более позднюю версию.

Замечание

--minimum-expected-tests 0 недопустим. Чтобы отключить код выхода с нуля тестов, используйте --ignore-exit-code 8.

Начиная с .NET 11 предварительной версии 6, --tl--terminalloggerи --tlp перенаправляются в MSBuild вместо тестового приложения. Начиная с .NET 12 предварительной версии 1, распознанные -mt и -multiThreaded формы также перенаправляются в MSBuild. Чтобы передать параметр приложения с одним из этих имен, поместите его после --.

Передайте параметры режима выполнения, такие как --help и --list-tests непосредственно dotnet test. Начиная с .NET 11 предварительной версии 6 пакет SDK проверяет режим выполнения, согласованный с тестируемым приложением. Если профиль запуска или TestingPlatformCommandLineArguments внедряет один из этих вариантов, запрошенная операция ПАКЕТА SDK и операция приложения не совпадают, и запуск завершается сбоем с диагностикой.

Примеры

  • Запустите тесты в 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"

  • Запустите все тестовые проекты, на которые ссылается обходный проект, с .NET 11 предварительной версии 7 или более поздней версии:

    dotnet test dirs.proj

  • Вывод списка тестов в формате JSON с .NET 11 предварительной версии 7 или более поздней версии:

    dotnet test --list-tests json

  • Запустите тестовое приложение MTP на основе C# с .NET 12 предварительной версии 1 или более поздней версии:

    dotnet test App.Tests.cs

  • Запустите тесты в текущем каталоге с расширением покрытия кода Microsoft. Тестовое приложение должно ссылаться Microsoft.Testing.Extensions.CodeCoverageнепосредственно или через конфигурацию тестового пакета SDK, которая включает в себя:

    dotnet test --coverage

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

    dotnet test --results-directory ./TestResults

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

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

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

    dotnet test --minimum-expected-tests 10

  • Требовать по крайней мере 5 тестов во всем выполнении и по крайней мере 2 теста в каждом тестовом модуле:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

  • Запустите тесты в 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