параметры командной строки VSTest.Console.exe

VSTest.Console.exe — это средство командной строки для выполнения тестов. Можно указать несколько параметров в любом порядке в командной строке. Эти параметры перечислены в параметрах командной строки "Общие".

Заметка

Адаптер MSTest в Visual Studio также работает в устаревшем режиме (эквивалентно выполнению тестов с mstest.exe) для обеспечения совместимости. В устаревшем режиме не удается воспользоваться функцией TestCaseFilter. Адаптер может переключиться в устаревший режим, если указан файл testettings, forcelegacymode имеет значение true в файле запуска или с помощью таких атрибутов, как HostType.

Чтобы запустить автоматизированные тесты на компьютере на основе архитектуры ARM, необходимо использовать VSTest.Console.exe.

Откройте командную строку разработчика, чтобы использовать программу командной строки, или вы можете найти это средство в %Program%\Microsoft Visual Studio\<версии>\<edition>\common7\ide\CommonExtensions\<Platform | Microsoft>.

Общие параметры командной строки

В следующей таблице перечислены часто используемые параметры дляVSTest.Console.exe и кратких описаний. Вы можете увидеть аналогичную сводку, введя VSTest.Console/? в командной строке. Полный справочник, включая внутренние и устаревшие коммутаторы, которые не перечислены здесь, см. в разделеvstest.console.exe параметры командной строки и, в частности, опущенные коммутаторы в репозитории vstest.

Выбор Описание
[имена тестовых файлов] Запустите тесты из указанных файлов. Разделите несколько имен тестовых файлов с пробелами.
Примеры: mytestproject.dll, mytestproject.dll myothertestproject.exe
/Settings:[ имя файла] Запустите тесты с дополнительными параметрами, такими как сборщики данных. Дополнительные сведения см. в разделе Настройка модульных тестов с помощью файла .runsettings
Пример: /Settings:local.runsettings
/Test:[имя теста] Выполните тесты с именами, содержащими предоставленные значения. Эта команда соответствует полному имени теста, включая пространство имен. Чтобы предоставить несколько значений, разделите их запятыми.
Пример: /Tests:TestMethod1,testMethod2
Параметр командной строки /Tests нельзя использовать с параметром командной строки /TestCaseFilter .
/Parallel Указывает, что тесты выполняются параллельно. По умолчанию можно использовать до всех доступных ядер на компьютере. Можно настроить количество ядер, используемых в файле параметров.
/InIsolation Выполняет тесты в изолированном процессе.
Эта изоляция делает процесс vstest.console.exe менее вероятным для остановки ошибки в тестах, но тесты могут выполняться медленнее.
/TestAdapterPath:[пути] Принудительно vstest.console.exe процесса использовать пользовательские адаптеры тестов из указанного пути (если таковые есть) в тестовом запуске.
Пример: /TestAdapterPath:[pathToCustomAdapters]
/Platform:[тип платформы] Принудительно задает используемую архитектуру платформы вместо платформы, определенной из текущей среды выполнения. Значения не учитывает регистр; Допустимые значения: , , , , , , Ppc64leRiscV64и LoongArch64. S390xARM64ARMx64x86
В Windows только x86 и x64 можно надежно принудительно принудить; указание ARM результатов x64 в большинстве систем. Не указывайте этот параметр для запуска в среде выполнения, которая не содержится в списке допустимых значений.
/Framework: [версии платформы] Целевая версия .NET, используемая для тестового выполнения.
Современные короткие формы платформы принимаются и анализируются средствами синтаксического анализа платформы NuGet, например net6.0net48, или net10.0 (а также длинных форм, таких как .NETFramework,Version=v4.8 и .NETCoreApp,Version=v10.0).
Устаревшие псевдонимы Framework35, , FrameworkCore10Framework40Framework45и FrameworkUap10 также принимаются.
TargetFrameworkAttribute используется для автоматического обнаружения этого параметра из сборки и по умолчанию, Framework40 когда атрибут отсутствует. Этот параметр необходимо указать явным образом, если удалить TargetFrameworkAttribute из сборок .NET Core.
Если целевая платформа указана как Framework35, тесты выполняются в режиме совместимости CLR 4.0.
Пример: /Framework:net8.0
/TestCaseFilter:[выражение] Выполните тесты, соответствующие заданному выражению.
< выражения >имеет свойство <формата>=<значение>[|<expression>].
Пример: /TestCaseFilter:"Priority=1"
Пример: /TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"
Параметр командной строки /TestCaseFilter нельзя использовать с параметром командной строки /Test .
Сведения о создании и использовании выражений см. в фильтра TestCase. При вводе фильтра непосредственно в оболочке см. выражения escape-фильтров в оболочке.
/Environment:[NAME]=[VALUE] Задает значение переменной среды для процесса тестового узла. Создает переменную, если она не существует, и переопределяет ее, если это делает. Этот параметр подразумевает /InIsolation и заставляет тесты выполняться в изолированном процессе. Укажите параметр несколько раз, чтобы задать несколько переменных. Короткая форма: /e.
Пример: /e:VARIABLE1=VALUE1
/? Отображает сведения об использовании.
/Loger:[URI/friendlyname] Укажите средство ведения журнала для результатов теста. Укажите параметр несколько раз, чтобы включить несколько средств ведения журнала.
Пример. Чтобы войти в файл результатов теста Visual Studio (TRX), используйте
/Loger:trx
[; LogFileName=<По умолчанию используется уникальное имя файла>]
Используйте LogFilePrefix=<prefix> вместо LogFileName того, чтобы хранить отдельный метки времени для каждого запуска. LogFileName задает явное имя и перезаписывает предыдущий файл, а LogFilePrefix не.
Дополнительные сведения см. в примере ведения журнала.
/ListTests:[имя файла] Перечисляет обнаруженные тесты из заданного контейнера тестов. Короткая форма: /lt.
Примечание. Параметр /TestCaseFilter не действует при перечислении тестов; он управляет только тем, какие тесты получают выполнение.
/Blame Выполняет тесты в режиме вины. Этот параметр полезен при изоляции проблемных тестов, которые приводят к сбою узла тестирования. При обнаружении сбоя создается файл последовательности в TestResults/<Guid>/<Guid>_Sequence.xml, который фиксирует порядок тестов, выполняемых до сбоя.
Вы также можете собирать аварийное завершение или зависание дампа, например /Blame:CollectDump;DumpType=full или /Blame:CollectHangDump;TestTimeout=90m;HangDumpType=mini. Эквивалентные dotnet test коммутаторы и --blame-crash--blame-hang.
Полные матрицы и требования к сбору дампов см. в разделе "Сборщик данных Вины".
/Diag:[имя файла] Записывает журналы диагностики трассировки в указанный файл.
Задайте уровень трассировки ( /Diag:<file name>;tracelevel=<off\|error\|warning\|info\|verbose> по умолчанию verbose).
/ResultsDirectory:[ путь] Каталог результатов теста будет создан в указанном пути, если он не существует.
Пример: /ResultsDirectory:<pathToResultsDirectory>
/ParentProcessId:[parentProcessId] Идентификатор процесса родительского процесса, ответственного за запуск текущего процесса.
/Port:[порт] Порт подключения сокета и получение сообщений о событии.
/Collect:[dataCollector friendlyName] Включает сборщик данных для тестового запуска. Дополнительные сведения.
@[file] Считывает дополнительные параметры из указанного файла ответа. Аргументы в файле разделены пробелами (пробелами или новыми линиями) и поддерживаются, поэтому параметры могут охватывать несколько строк.
Пример: vstest.console.exe @options.rsp

Кончик

Параметры и значения не учитывает регистр.

Примеры

Синтаксис для выполнения vstest.console.exe:

vstest.console.exe [TestFileNames] [Options]

По умолчанию команда возвращает значение 0 при обычном выходе, даже если тесты не обнаружены. Если вы хотите вернуть ненулевое значение, если тесты не обнаружены, используйте параметр <TreatNoTestsAsError>true</TreatNoTestsAsError> запуска.

Следующая команда выполняет vstest.console.exe для myTestProject.dllбиблиотеки тестов:

vstest.console.exe myTestProject.dll

Следующая команда выполняется vstest.console.exe с несколькими тестовых файлами. Отдельные имена тестовых файлов с пробелами:

vstest.console.exe myTestFile.dll myOtherTestFile.dll

Следующая команда выполняется vstest.console.exe с несколькими параметрами. Он выполняет тесты в файле myTestFile.dll в изолированном процессе и использует параметры, указанные в файле Local.RunSettings. Кроме того, он выполняет тесты, помеченные "Priority=1", и записывает результаты в файл .trx.

vstest.console.exe myTestFile.dll /Settings:Local.RunSettings /InIsolation /TestCaseFilter:"Priority=1" /Logger:trx

Следующая команда запускает vstest.console.exe с параметром /blame для myTestProject.dllбиблиотеки тестов:

vstest.console.exe myTestFile.dll /blame

Если произошел сбой тестового узла, создается файл sequence.xml. Файл содержит полные имена тестов в их последовательности выполнения до определенного теста, выполняемого во время сбоя.

Если тестового узла нет сбоя, файл sequence.xml не будет создан.

Пример созданного sequence.xml файла:

<?xml version="1.0"?>
<TestSequence>
  <Test Name="TestProject.UnitTest1.TestMethodB" Source="D:\repos\TestProject\TestProject\bin\Debug\TestProject.dll" />
  <Test Name="TestProject.UnitTest1.TestMethodA" Source="D:\repos\TestProject\TestProject\bin\Debug\TestProject.dll" />
</TestSequence>

В этом случае <Test Name> указанный последний — это тест, выполняемый во время сбоя.

Коды выхода

vstest.console.exe возвращает один из двух кодов выхода:

Код Значение
0 Успех. Запрошенная операция завершена и для тестового выполнения все выполненные тесты прошли.
1 Неудача. Например, произошел сбой одного или нескольких тестов, произошла ошибка выполнения, командная строка была недопустима или отсутствует, не удалось загрузить источник теста или отменить выполнение.

Процесс никогда не возвращает другое значение. При выполнении тестов dotnet testпакет SDK .NET отображает код выхода, отличный от нуля, когда выполнение завершается так же.

Когда обнаружение не находит соответствующие тесты, средство выполнения выводит предупреждение , а не ошибку, и по умолчанию возвращается 0. Чтобы выполнить выполнение, которое обнаруживает или выбирает ноль тестов 1 , возвращается вместо этого, задайте <TreatNoTestsAsError>true</TreatNoTestsAsError> в элементе RunConfiguration файла runettings . Дополнительные сведения см. в разделе "Настройка модульных тестов" с помощью файла .runsettings.

Выражения escape-фильтра в оболочке

Выражение /TestCaseFilter анализируется как оболочкой, так и тестовой платформой, поэтому некоторые символы нуждаются в переходе от оболочки, прежде чем vstest.console.exe получать их. Процитирование всего выражения, как и в примерах, приведенных выше в этой статье, позволяет избежать большинства проблем. В следующих случаях требуется дополнительная помощь:

  • PowerShell: запятая (,) — это оператор массива, а точка с запятой (;) — это разделитель инструкций. Процитировать все выражение фильтра, чтобы он прошел через буквально, например /TestCaseFilter:"FullyQualifiedName=MyNamespace.MyClass.MyMethod".

  • Bash и zsh (Linux и macOS): escape ! с обратной косой чертой при использовании !~ оператора (не содержится), например --filter FullyQualifiedName\!~IntegrationTests с dotnet test. Кроме того, кавычки, содержащие символы с особым значением для оболочки, например <>, или , в списке аргументов универсального типа:

    dotnet test --filter "FullyQualifiedName=MyNamespace.MyClass<Type1,Type2>.MyMethod"

Полный справочник по фильтрации и поддерживаемые свойства для каждой платформы тестирования см. в разделе "Фильтр TestCase".

Пример логирования

Каждый средство ведения журнала определяет собственные параметры. В отличие от trx, средство ведения журнала консоли позволяет задать уровень детализации. Дополнительные сведения введите VSTest.Console/? в командной строке.

Ниже приведен пример для средства ведения журнала консоли:

vstest.console.exe myTestFile.dll /logger:console;verbosity=detailed

Поддерживаемые уровни детализации включают тихие, минимальные, обычные и подробные.

В PowerShell необходимо использовать кавычки:

vstest.console.exe myTestFile.dll /logger:"console;verbosity=detailed"

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

Пример UWP

Для UWP файл appxrecipe должен ссылаться вместо библиотеки DLL.

vstest.console.exe /Logger:trx /Platform:x64 /framework:frameworkuap10 UnitTestsUWP\bin\x64\Release\UnitTestsUWP.build.appxrecipe

Переменные среды

Тестовая платформа распознает несколько переменных среды. Ниже приведены наиболее полезные при выполнении тестов из командной строки. Полный список см. в разделе "Переменные среды", понятные тестовой платформой в репозитории vstest.

Variable Описание
VSTEST_CONNECTION_TIMEOUT Время ожидания (в секундах) для установления подключений между компонентами тестовой платформы (vstest.console.exe, testhost и сборщиком данных). Значение по умолчанию — 90. Увеличьте его на медленных компьютерах или когда задержка в сети приводит к истечению времени ожидания подключения.
VSTEST_DIAG Включает ведение журнала диагностики и задает путь к файлу журнала. Эквивалентен параметру /Diag .
VSTEST_DIAG_VERBOSITY Задает подробность ведения журнала диагностики при VSTEST_DIAG включении. Допустимые значения: Verbose, WarningInfo, и Error (по умолчанию — Verbose).
VSTEST_HOST_DEBUG Задайте для любого непустого значения, чтобы включить отладку процесса testhost.
VSTEST_RUNNER_DEBUG Задайте для любого непустого значения, чтобы включить отладку средства выполнения (vstest.console.exe).
VSTEST_DUMP_PATH Переопределяет каталог по умолчанию, в котором хранятся аварийные дампы.
VSTEST_DUMP_FORCEPROCDUMP Задайте для любого непустого значения, чтобы принудительно использовать ProcDump для сбора аварийных дампов.
VSTEST_DISABLE_UTF8_CONSOLE_ENCODING Установите для 1 отключения кодирования UTF-8 в выходных данных консоли.
VSTEST_CONSOLE_PATH Путь к исполняемому файлу vstest.console.exe, используемому приложением пересылки пакета SDK dotnet test .NET. Эквивалентно выполнению -p:VSTestConsolePathdotnet test в проекте.

Связанные материалы

  • Last updated on