dotnet test
Эта статья относится к: ✔️ пакету 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
Команда dotnet test
служит для выполнения модульных тестов в решении. Команда dotnet test
создает решение и запускает тестовое приложение узла для каждого тестового проекта в решении с помощью VSTest
. Узел тестирования выполняет тесты в данном проекте с помощью платформы тестирования, например MSTest, NUnit или xUnit, а также сообщает об успешном или неудачном выполнении каждого теста. Если все тесты выполнены успешно, средство выполнения тестов возвращает код 0. Если же любой тест завершается с ошибкой, средство выполнения возвращает 1.
Примечание
dotnet test
изначально предназначен для поддержки только VSTest
тестовых проектов на основе. Последние версии тестовых платформ добавляют поддержку Microsoft.Testing.Platform. Эта альтернативная тестовая платформа является более упрощенной и быстрой, чем VSTest
и поддерживается dotnet test
с разными параметрами командной строки. Дополнительные сведения см. в разделе Microsoft.Testing.Platform.
Для проектов с несколькими целевыми платформами тесты запускаются для каждой из них. Тестовый узел и платформа модульных тестов упаковываются в пакеты 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 или системах сборки, где требуется явно контролировать время восстановления.
Сведения об управлении веб-каналами NuGet см. в документации по dotnet restore
.
При выполнении этой команды запускается асинхронное фоновое скачивание оповестительных манифестов для рабочих нагрузок. Если скачивание по-прежнему выполняется по завершении этой команды, оно останавливается. Дополнительные сведения см. в разделе Оповестительные манифесты.
PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Путь к тестовому проекту.
- Путь к решению.
- Путь к каталогу, содержащему проект или решение.
- Путь к DLL-файлу тестового проекта.
- Путь к файлу тестового проекта .exe .
Если это не указано, эффект совпадает с использованием аргумента
DIRECTORY
для указания текущего каталога.
Предупреждение
Критические изменения в параметрах:
- Начиная с .NET 7: переключитесь
-a
на псевдоним--arch
вместо--test-adapter-path
- Начиная с .NET 7: переключитесь
-r
на псевдоним--runtime
вместо--results-directory
Предупреждение
При использовании Microsoft.Testing.Platform
см. сведения об интеграции dotnet test для поддерживаемых параметров. Как правило, каждый вариант, не связанный с тестированием, поддерживается, хотя каждый вариант, связанный с тестированием, не поддерживается как есть.
--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 в пути будет использоваться для выполнения тестов. Дополнительные сведения см. на следующих ресурсах:-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
проекте, присвойв свойству MSBuildDefineConstants
значениеDEV
:dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
Запустите тесты в
test1
проекте, присвойв свойству MSBuildTestTfmsInParallel
значениеfalse
:dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
--filter <EXPRESSION>
Параметр <Expression>
имеет следующий формат: <property><operator><value>[|&<Expression>]
.
<property>
— это атрибут Test Case
. Ниже приведены свойства, поддерживаемые популярными платформами модульных тестов.
Платформа тестирования | Поддерживаемые свойства |
---|---|
MSTest |
|
xUnit |
|
NUnit |
|
<operator>
описывает связь между свойством и значением:
Оператор | Function |
---|---|
= |
Точное совпадение |
!= |
Неточное соответствие |
~ |
Содержит |
!~ |
Не содержит |
<value>
— это строка. Поиск выполняется без учета регистра.
Выражение без <operator>
автоматически считается функцией contains
для свойства FullyQualifiedName
(например, dotnet test --filter xyz
совпадает с dotnet test --filter FullyQualifiedName~xyz
).
Выражения можно объединять с условными операторами.
Оператор | Function |
---|---|
| |
ИЛИ |
& |
И |
При использовании условных операторов выражения можно заключать в скобки (например, (Name~TestMethod1) | (Name~TestMethod2)
).
Дополнительные сведения и примеры использования фильтрации при выборочном модульном тестировании см. в статье Выполнение выборочных модульных тестов.
Отзыв о .NET
.NET — это проект с открытым исходным кодом. Выберите ссылку, чтобы оставить отзыв: