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

dotnet test с использованием VSTest

Эта статья относится к: ✔️ пакету SDK для .NET 6 и более поздних версий

Имя

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

Synopsis

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [--test-adapter-path <ADAPTER_PATH>]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [--blame]
    [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>]
    [--blame-crash-collect-always]
    [--blame-hang]
    [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>]
    [--disable-build-servers]
    [-f|--framework <FRAMEWORK>]
    [-e|--environment <NAME="VALUE">]
    [--filter <EXPRESSION>]
    [--interactive]
    [-l|--logger <LOGGER>]
    [--no-build]
    [--nologo]
    [--no-restore]
    [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>]
    [--results-directory <RESULTS_DIR>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>]
    [-t|--list-tests]
    [--tl:[auto|on|off]]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

Description

Команда dotnet test служит для выполнения модульных тестов в решении. Команда dotnet test создает решение и запускает тестовое приложение узла для каждого тестового проекта в решении с помощью VSTest. Узел тестирования выполняет тесты в данном проекте с помощью платформы тестирования, например MSTest, NUnit или xUnit, а также сообщает об успешном или неудачном выполнении каждого теста. Если все тесты выполнены успешно, средство выполнения тестов возвращает код 0. Если же любой тест завершается с ошибкой, средство выполнения возвращает 1.

Замечание

dotnet test изначально предназначен для поддержки только VSTestтестовых проектов на основе. Последние версии тестовых платформ добавляют поддержку Microsoft.Testing.Platform. Эта альтернативная тестовая платформа является более упрощенной и быстрой, чем VSTest и поддерживается dotnet test с разными параметрами командной строки. Дополнительные сведения см. в статье dotnet test with MTP.

Для проектов с несколькими целевыми платформами тесты запускаются для каждой из них. Тестовый узел и платформа модульных тестов упаковываются в пакеты NuGet и восстанавливаются как обычные зависимости проекта. Начиная с пакета SDK для .NET 9 эти тесты выполняются параллельно. Чтобы отключить параллельное выполнение, задайте TestTfmsInParallel для свойства MSBuild значение false. Дополнительные сведения см. в разделе "Параллельное выполнение тестов" и пример командной строки далее в этой статье.

Тестовый проект указывает средство выполнения тестов с помощью обычного элемента <PackageReference>, как показано в следующем примере файла проекта:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
    <PackageReference Include="xunit" Version="2.8.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.1" />
  </ItemGroup>

</Project>

Где Microsoft.NET.Test.Sdk — это тестовый узел, xunit — платформа тестирования. xunit.runner.visualstudio — это адаптер теста, позволяющий платформе xUnit работать с тестовым узлом.

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

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

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

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

Скачивание манифестов рабочих нагрузок

При выполнении этой команды запускается асинхронное фоновое скачивание оповестительных манифестов для рабочих нагрузок. Если скачивание по-прежнему выполняется по завершении этой команды, оно останавливается. Дополнительные сведения см. в разделе Оповестительные манифесты.

Arguments

  • PROJECT | SOLUTION | DIRECTORY | DLL | EXE

    • Путь к тестовому проекту.
    • Путь к решению.
    • Путь к каталогу, содержащему проект или решение.
    • Путь к DLL-файлу тестового проекта.
    • Путь к файлу тестового проекта .exe .

    Если это не указано, эффект совпадает с использованием аргумента DIRECTORY для указания текущего каталога.

Options

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

Критические изменения в параметрах:

  • Начиная с .NET 7: переключитесь -a на псевдоним --arch вместо --test-adapter-path
  • Начиная с .NET 7: переключитесь -r на псевдоним --runtime вместо --results-directory

  • --test-adapter-path <ADAPTER_PATH>

    Путь к пользовательским адаптерам, используемым для тестового запуска.

    Короткая форма -a , доступная в версиях пакета SDK для .NET до 7.

  • -a|--arch <ARCHITECTURE>

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

  • --artifacts-path <ARTIFACTS_DIR>

    Все выходные файлы сборки из выполняемой команды будут отправляться в вложенные папки в соответствии с указанным путем, разделенным проектом. Дополнительные сведения см. в разделе "Макет выходных данных артефактов". Доступно с пакета SDK для .NET 8.

  • --blame

    Выполнение тестов в режиме обвинения. Этот параметр полезен при изоляции проблемных тестов, которые приводят к аварийному завершению хоста для тестов. При обнаружении сбоя он создает файл последовательности в TestResults/<Guid>/<Guid>_Sequence.xml, который фиксирует порядок тестов, выполненных до сбоя.

    Этот параметр не создает дамп памяти и не полезен при зависаниях теста.

  • --blame-crash (Доступно начиная с пакета SDK для .NET 5.0)

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

    Данные для дампа исключений в управляемом коде будут собираться в .NET 5.0 и более поздних версий автоматически. Этот параметр создаст дамп для TestHost или любого дочернего процесса, который также выполнялся в .NET 5.0 и завершился сбоем. Аварийное завершение в машинном коде не приведет к созданию дампа. Этот параметр работает в Windows, macOS и Linux.

    Аварийные дампы в машинном коде или при использовании .NET Core 3.1 или более ранних версий можно собирать только в Windows с помощью Procdump. Каталог, содержащий файлы procdump.exe и procdump64.exe, должен быть включен в переменную среды PATH или PROCDUMP_PATH. Скачать средства. Подразумевает --blame.

    Чтобы собрать аварийный дамп из собственного приложения, запущенного в NET 5.0 или более поздней версии, можно принудительно использовать Procdump, задав для переменной среды VSTEST_DUMP_FORCEPROCDUMP значение 1.

  • --blame-crash-dump-type <DUMP_TYPE> (Доступно начиная с пакета SDK для .NET 5.0)

    Тип собираемого аварийного дампа. Поддерживаемые типы дампов : full (по умолчанию) и mini. Подразумевает --blame-crash.

  • --blame-crash-collect-always (Доступно начиная с пакета SDK для .NET 5.0)

    Собирает аварийный дамп при ожидаемом и непредвиденном завершении процесса хоста для тестов.

  • --blame-hang (Доступно начиная с пакета SDK для .NET 5.0)

    Выполняет тесты в режиме обвинения и собирает дамп зависания при превышении тестом заданного времени ожидания.

  • --blame-hang-dump-type <DUMP_TYPE> (Доступно начиная с пакета SDK для .NET 5.0)

    Тип собираемого аварийного дампа. full, mini или none. Если указан тип none, процесс хоста для тестов завершается по истечении времени ожидания, но дамп не собирается. Подразумевает --blame-hang.

  • --blame-hang-timeout <TIMESPAN> (Доступно начиная с пакета SDK для .NET 5.0)

    Время ожидания каждого теста, после которого дамп зависания активируется, и тестирование хост-процесса и все его дочерние процессы создают дамп и завершаются. Значение времени ожидания указывается в одном из следующих форматов:

    • 1,5 ч, 1,5 часа
    • 90 м, 90 мин, 90 минут
    • 5400 с, 5400 сек, 5400 секунд
    • 5 400 000 мс, 5 400 000 мсек, 5 400 000 миллисекунд

    Если единица измерения не указана (например, 5 400 000), предполагается, что значение указано в миллисекундах. При использовании вместе с тестами, управляемыми данными, поведение времени ожидания зависит от используемого адаптера теста. Для xUnit, NUnit и MSTest 2.2.4+время ожидания обновляется после каждого тестового случая. Для MSTest до версии 2.2.4 время ожидания используется для всех тестовых случаев. Эта возможность поддерживается в Windows с netcoreapp2.1 и более поздних версий, в Linux с netcoreapp3.1 и более поздних версий, а также в macOS с net5.0 и более поздних версий. Подразумевает --blame и --blame-hang.

  • -c|--configuration <CONFIGURATION>

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

  • --collect <DATA_COLLECTOR_NAME>

    Включает сборщик данных для тестового запуска. Дополнительные сведения см. в разделе Мониторинг и анализ тестового запуска.

    Например, можно собирать покрытие кода с помощью --collect "Code Coverage" параметра. Дополнительные сведения см. в разделе "Использование покрытия кода", "Настройка анализа покрытия кода" и "Проблема GitHub dotnet/docs#34479".

    Для сбора покрытия кода можно также использовать обложку--collect "XPlat Code Coverage" с помощью параметра.

  • -d|--diag <LOG_FILE>

    Включает режим диагностики для платформы тестирования и записывает диагностические сообщения в указанный файл и в файлы рядом с ним. Процесс, который заносит сообщения в журнал, определяет, какие файлы создаются, например *.host_<date>.txt для журнала тестового узла и *.datacollector_<date>.txt для журнала сборщика данных.

  • --disable-build-servers

    Принудительно заставляет команду игнорировать все постоянные серверы сборки. Этот параметр предоставляет согласованный способ отключить все использование кэширования сборки, которая заставляет сборку с нуля. Сборка, которая не зависит от кэшей, полезна, когда кэши могут быть повреждены или неверны по какой-то причине. Доступно с пакета SDK для .NET 7.

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

    Задает значение переменной среды. Создает переменную, если она не существует, переопределяется, если она существует. Использование этого параметра приведет к принудительному выполнению тестов в изолированном процессе. Параметр можно указать несколько раз для предоставления нескольких переменных.

  • -f|--framework <FRAMEWORK>

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

  • --filter <EXPRESSION>

    Фильтрует тесты в текущем проекте с помощью заданного выражения. Выполняются только тесты, соответствующие выражению фильтра. Дополнительные сведения см. в разделе Сведения о параметре "Фильтр". Дополнительные сведения и примеры использования фильтрации при выборочном модульном тестировании см. в статье Выполнение выборочных модульных тестов.

  • -?|-h|--help

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

  • --interactive

    Позволяет команде остановить и ждать ввода или действия пользователя. Например, чтобы завершить проверку подлинности.

  • -l|--logger <LOGGER>

    Задает средство ведения журнала для результатов тестирования и при необходимости переключается для средства ведения журнала. Укажите этот параметр несколько раз, чтобы включить несколько средств ведения журнала. Дополнительные сведения см. в разделе "Результаты теста отчетов", "Коммутаторы для средств ведения журнала" и примеры, приведенные далее в этой статье.

    Чтобы передать переключатели командной строки в средство ведения журнала:

    • Используйте полное имя коммутатора, а не сокращенную форму (например, verbosity вместо v).
    • Опустить любые ведущие дефисы.
    • Замените пространство, разделяющее каждый коммутатор точкой с запятой ;.
    • Если параметр имеет значение, замените разделитель двоеточия между этим коммутатором и его значением знака =равенства.

    Например, -v:detailed --consoleLoggerParameters:ErrorsOnly станет verbosity=detailed;consoleLoggerParameters=ErrorsOnly.

  • --no-build

    Не выполняет сборку тестового проекта перед запуском. Он также неявно задает флаг --no-restore.

  • --nologo

    Запуск тестов без отображения баннера TestPlatform Майкрософт. Доступно, начиная с пакета SDK для .NET Core 3.0.

  • --no-restore

    Не выполняет неявное восстановление при выполнении команды.

  • -o|--output <OUTPUT_DIRECTORY>

    Каталог, в котором выполняется поиск двоичных файлов для выполнения. Если значение не указано, путь по умолчанию — ./bin/<configuration>/<framework>/. Для проектов с несколькими целевыми платформами (с помощью свойства TargetFrameworks) необходимо также определить --framework при указании этого параметра. dotnet test всегда запускает тесты из выходного каталога. Для использования ресурсов тестирования в выходном каталоге можно использовать AppDomain.BaseDirectory.

    • Пакет SDK для .NET 7.0.200 и более поздних версий

      Если указать --output параметр при выполнении этой команды в решении, интерфейс командной строки выдает предупреждение (ошибка в версии 7.0.200) из-за неясной семантики выходного пути. Этот --output параметр запрещен, так как все выходные данные всех встроенных проектов будут скопированы в указанный каталог, который не совместим с многоцелыми проектами, а также проектами с различными версиями прямых и транзитивных зависимостей. Дополнительные сведения см. в разделе "Параметр уровня --output решения" больше недействителен для команд, связанных со сборкой.

  • --os <OS>

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

  • --results-directory <RESULTS_DIR>

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

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

  • -r|--runtime <RUNTIME_IDENTIFIER>

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

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

  • -s|--settings <SETTINGS_FILE>

    Файл .runsettings, который необходимо использовать для проведения тестов. Элемент TargetPlatform (x86|x64) не влияет на dotnet test. Чтобы запускать тесты для x86, установите версию .NET Core x86. Разрядность dotnet.exe в пути будет использоваться для выполнения тестов. Дополнительные сведения см. в следующих ресурсах:

  • -t|--list-tests

    Вывод списка обнаруженных тестов вместо выполнения тестов.

  • --tl:[auto|on|off]

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

    Средство ведения журнала терминала показывает этап восстановления, за которым следует этап сборки. На каждом этапе в нижней части терминала отображаются строительные проекты. Каждый проект, который создает выходные данные как целевого объекта MSBuild, который в настоящее время создается, так и время, затраченное на этот целевой объект. Эти сведения можно найти, чтобы узнать больше о сборке. После завершения сборки проекта записывается один раздел "сборка завершена", который записывает:

    • Имя созданного проекта.
    • Целевая платформа (если она используется с несколькими целевыми объектами).
    • Состояние этой сборки.
    • Основные выходные данные этой сборки (которая гиперссылок).
    • Любая диагностика, созданная для этого проекта.

    Этот параметр доступен начиная с .NET 8.

  • -v|--verbosity <LEVEL>

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

  • args

    Задает дополнительные аргументы, передаваемые адаптеру. Для разделения аргументов используйте пробел.

    Список возможных аргументов зависит от указанного поведения:

    • При указании проекта, решения или каталога или, если этот аргумент опущен, вызов перенаправлен msbuild. В этом случае доступные аргументы можно найти в документации dotnet msbuild.
    • При указании .dll или .exe вызов пересылается в vstest. В этом случае доступные аргументы можно найти в документации dotnet vstest.

  • Аргументы RunSettings

Встроенные RunSettings передаются как последние аргументы в командной строке после "-- " (обратите внимание на пробел после "--"). Встроенные RunSettings указываются как пары [name]=[value]. Несколько пар [name]=[value] разделяются пробелами.

Пример: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Дополнительные сведения см. в статье о передаче аргументов RunSettings с помощью командной строки.

Примеры

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

    dotnet test

  • Выполнение тестов в проекте test1:

    dotnet test ~/projects/test1/test1.csproj

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

    dotnet test ~/projects/test1/bin/debug/test1.dll

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

    dotnet test --logger trx

  • Запустите тесты в проекте в текущем каталоге и создайте файл покрытия кода с помощью покрытия Microsoft Code:

    dotnet test --collect "Code Coverage"

  • Запустите тесты в проекте в текущем каталоге и создайте файл покрытия кода с помощью Coverlet (после установки интеграции сборщиков Coverlet):

    dotnet test --collect:"XPlat Code Coverage"

  • Выполнение тестов в проекте в текущем каталоге и вывод журнала с подробными сведениями в консоль:

    dotnet test --logger "console;verbosity=detailed"

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

    dotnet test --logger "trx;logfilename=testResults.trx"

    Так как имя файла журнала указано, то же имя используется для каждой целевой платформы в случае с несколькими целевыми проектами. Выходные данные для каждой целевой платформы перезаписывают выходные данные для предыдущих целевых платформ. Файл создается в папке TestResults в папке тестового проекта, так как относительные пути относятся к этой папке. В следующем примере показано, как создать отдельный файл для каждой целевой платформы.

  • Запустите тесты в проекте в текущем каталоге и войдите с помощью средства ведения журнала trx в файлы в папке TestResults с именами файлов, уникальными для каждой целевой платформы:

    dotnet test --logger:"trx;LogFilePrefix=testResults"

  • Запустите тесты в проекте в текущем каталоге и войдите с помощью средства ведения журнала HTML, чтобы testResults.html в папке TestResults :

    dotnet test --logger "html;logfilename=testResults.html"

  • Выполнение тестов в проекте в текущем каталоге и тестов отчетов, которые выполнялись при сбое узла тестирования:

    dotnet test --blame

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

    dotnet test ~/projects/test1/test1.csproj -bl

  • Запустите тесты в test1 проекте, присвойв свойству MSBuild DefineConstants значение DEV:

    dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"

  • Запустите тесты в test1 проекте, присвойв свойству MSBuild TestTfmsInParallel значение false:

    dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false

Сведения о параметре "Фильтр"

--filter <EXPRESSION>

Параметр <Expression> имеет следующий формат: <property><operator><value>[|&<Expression>].

<property> — это атрибут Test Case. Ниже приведены свойства, поддерживаемые популярными платформами модульных тестов.

Платформа тестирования Поддерживаемые свойства
MSTest
  • ПолностьюqualifiedName
  • Имя
  • ИмяКласса
  • Priority
  • TestCategory
xUnit
  • ПолностьюqualifiedName
  • Отображаемое имя
  • Категория
NUnit
  • ПолностьюqualifiedName
  • Имя
  • Категория
  • Priority

<operator> описывает связь между свойством и значением:

Operator Функция
= Точное совпадение
!= Неточное соответствие
~ Содержит
!~ Не содержит

<value> — это строка. Поиск выполняется без учета регистра.

Выражение без <operator> автоматически считается функцией contains для свойства FullyQualifiedName (например, dotnet test --filter xyz совпадает с dotnet test --filter FullyQualifiedName~xyz).

Выражения можно объединять с условными операторами.

Operator Функция
| OR
& AND

При использовании условных операторов выражения можно заключать в скобки (например, (Name~TestMethod1) | (Name~TestMethod2)).

Дополнительные сведения и примеры использования фильтрации при выборочном модульном тестировании см. в статье Выполнение выборочных модульных тестов.

См. также

  • Last updated on