dotnet test

Статья
03/27/2024

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

Имя.

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

Краткие сведения

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>]
    [-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]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

Description

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

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

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

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

  <PropertyGroup>
    <TargetFramework>net6.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 или системах сборки, где требуется явно контролировать время восстановления.

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

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

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

Аргументы

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Путь к тестовому проекту.
- Путь к решению.
- Путь к каталогу, содержащему проект или решение.
- Путь к DLL-файлу тестового проекта.
- Путь к файлу тестового проекта .exe .
Если это не указано, эффект совпадает с использованием аргумента DIRECTORY для указания текущего каталога.

Параметры

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

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

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

--test-adapter-path <ADAPTER_PATH>

Путь к каталогу для поиска дополнительных адаптеров теста. Проверяются только DLL-файлы с суффиксом .TestAdapter.dll. Если не указано, выполняется поиск по каталогу тестового DLL.

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

--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 для журнала сборщика данных.
-e|--environment <NAME="VALUE">

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

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

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

-?|-h|--help

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

--interactive

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

-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 в пути будет использоваться для выполнения тестов. Дополнительные сведения см. на следующих ресурсах:
- Настройка модульных тестов с помощью файла .runsettings.
- Настройка тестового запуска
-t|--list-tests

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

-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
```
Выполнение тестов в проекте в текущем каталоге и создание файла с объемом протестированного кода (после установки интеграции сборщиков Coverlet):
```
dotnet test --collect:"XPlat Code Coverage"
```
Выполнение тестов в проекте в текущем каталоге и создание файла с объемом протестированного кода (только Windows):
```
dotnet test --collect "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
```
Запустите тесты в проекте, указав -bl аргумент msbuild(двоичный test1 журнал) для следующих значений:
```
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	FullyQualifiedName Имя. ClassName Приоритет TestCategory
xUnit	FullyQualifiedName DisplayName Категория
NUnit	FullyQualifiedName Имя. Категория Приоритет

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

Оператор	Function
`=`	Точное совпадение
`!=`	Неточное соответствие
`~`	Содержит
`!~`	Не содержит

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

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

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

Оператор	Function
`\|`	ИЛИ
`&`	И

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

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

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

dotnet test

Имя.

Краткие сведения

Description

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

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

Аргументы

Параметры

Примеры

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

См. также

Обратная связь

Дополнительные ресурсы