VSTest.Console.exe Befehlszeilenoptionen

VSTest.Console.exe ist das Befehlszeilentool zum Ausführen von Tests. Sie können mehrere Optionen in beliebiger Reihenfolge in der Befehlszeile angeben. Diese Optionen werden in allgemeinen Befehlszeilenoptionenaufgeführt.

Anmerkung

Der MSTest-Adapter in Visual Studio funktioniert auch im Legacymodus (äquivalent zum Ausführen von Tests mit mstest.exe) zur Kompatibilität. Im Legacymodus kann das Feature "TestCaseFilter" nicht genutzt werden. Der Adapter kann in den Legacymodus wechseln, wenn eine Testsettings Datei angegeben wird, forcelegacymode auf true in einer Runsettings-Datei oder mithilfe von Attributen wie HostTypefestgelegt ist.

Um automatisierte Tests auf einem ARM-architekturbasierten Computer auszuführen, müssen Sie VSTest.Console.exeverwenden.

Öffnen Sie Entwickler-Eingabeaufforderung, um das Befehlszeilentool zu verwenden, oder suchen Sie das Tool in %Program Files(x86)%\Microsoft Visual Studio\<Version>\<Edition>\common7\ide\CommonExtensions\<Platform | Microsoft>.

Allgemeine Befehlszeilenoptionen

In der folgenden Tabelle sind die häufig verwendeten Optionen für VSTest.Console.exe und kurze Beschreibungen aufgeführt. Sie können eine ähnliche Zusammenfassung sehen, indem Sie VSTest.Console/? in eine Befehlszeile eingeben. Die vollständige Referenz, einschließlich interner und legacy-Switches, die hier nicht aufgeführt sind, finden Sie unter vstest.console.exe Befehlszeilenoptionen und speziell ausgelassenen Switches im Vstest-Repository.

Option Beschreibung
[Testdateinamen] Führen Sie Tests aus den angegebenen Dateien aus. Trennen Sie mehrere Testdateinamen durch Leerzeichen.
Beispiele: mytestproject.dll, mytestproject.dll myothertestproject.exe
/Settings:[Dateinamen] Führen Sie Tests mit zusätzlichen Einstellungen wie Datensammler aus. Weitere Informationen finden Sie unter Konfigurieren von Komponententests mithilfe einer RUNSETTINGS-Datei
Beispiel: /Settings:local.runsettings
/Tests:[Testname] Führen Sie Tests mit Namen aus, die die bereitgestellten Werte enthalten. Dieser Befehl entspricht dem vollständigen Testnamen, einschließlich des Namespaces. Um mehrere Werte bereitzustellen, trennen Sie sie durch Kommas.
Beispiel: /Tests:TestMethod1,testMethod2
Die Befehlszeilenoption "/Tests " kann nicht mit der Befehlszeilenoption "/TestCaseFilter " verwendet werden.
/Parallel Gibt an, dass die Tests parallel ausgeführt werden. Standardmäßig können bis zu alle verfügbaren Kerne auf dem Computer verwendet werden. Sie können die Anzahl der Kerne konfigurieren, die in einer Einstellungsdatei verwendet werden sollen.
/InIsolation Führt die Tests in einem isolierten Prozess aus.
Diese Isolation macht den vstest.console.exe Prozess weniger wahrscheinlich bei einem Fehler in den Tests beendet, aber Tests können langsamer ausgeführt werden.
/TestAdapterPath:[Pfad] Erzwingt den vstest.console.exe Prozess, benutzerdefinierte Testadapter aus einem angegebenen Pfad (sofern vorhanden) in der Testausführung zu verwenden.
Beispiel: /TestAdapterPath:[pathToCustomAdapters]
/Platform:[Plattformtyp] Erzwingt die Verwendung der gegebenen Plattformarchitektur anstelle der Plattform, die von der aktuellen Laufzeit bestimmt wird. Bei Werten wird die Groß-/Kleinschreibung nicht beachtet; die akzeptierten Werte sind x86, , x64, ARM, S390xARM64, , Ppc64leund LoongArch64RiscV64.
Auf Windows können nur x86 und x64 zuverlässig erzwungen werden; die Ergebnisse ARM in x64 werden auf den meisten Systemen angegeben. Geben Sie diese Option nicht an, die auf einer Laufzeit ausgeführt werden soll, die nicht in der Liste der gültigen Werte enthalten ist.
/Framework: [Framework-Version] .NET-Zielversion, die für die Testausführung verwendet werden soll.
Moderne Framework-Kurzformen werden vom NuGet-Framework-Parser akzeptiert und analysiert, z net48. B. , net6.0oder net10.0 (sowie die langen Formulare wie .NETFramework,Version=v4.8 und .NETCoreApp,Version=v10.0).
Die älteren Aliase Framework35, Framework40, Framework45, FrameworkCore10und FrameworkUap10 werden ebenfalls akzeptiert.
TargetFrameworkAttribute wird verwendet, um diese Option automatisch aus Der Assembly zu erkennen, und standardmäßig Framework40 , wenn das Attribut nicht vorhanden ist. Sie müssen diese Option explizit angeben, wenn Sie das TargetFrameworkAttribute- aus Ihren .NET Core-Assemblys entfernen.
Wenn das Zielframework als Framework35angegeben wird, werden die Tests im CLR 4.0 -Kompatibilitätsmodus ausgeführt.
Beispiel: /Framework:net8.0
/TestCaseFilter:[Ausdruck] Führen Sie Tests aus, die dem angegebenen Ausdruck entsprechen.
<Ausdruck> ist das Format <Eigenschaft>=<Wert>[|<Ausdruck>].
Beispiel: /TestCaseFilter:"Priority=1"
Beispiel: /TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"
Die Befehlszeilenoption "/TestCaseFilter " kann nicht mit der Befehlszeilenoption "/Tests " verwendet werden.
Informationen zum Erstellen und Verwenden von Ausdrücken finden Sie unter TestCase-Filter. Wenn Sie einen Filter direkt in eine Shell eingeben, lesen Sie Escapefilterausdrücke in der Shell.
/Environment:[NAME]=[WERT] Legt den Wert einer Umgebungsvariable für den Testhostprozess fest. Erstellt die Variable, wenn sie nicht vorhanden ist, und setzt sie außer Kraft, wenn dies der Fall ist. Diese Option impliziert /InIsolation und erzwingt die Ausführung der Tests in einem isolierten Prozess. Geben Sie die Option mehrmals an, um mehrere Variablen festzulegen. Kurzform: /e.
Beispiel: /e:VARIABLE1=VALUE1
/? Zeigt Nutzungsinformationen an.
/Logger:[uri/friendlyname] Geben Sie einen Logger für Testergebnisse an. Geben Sie den Parameter mehrmals an, um mehrere Logger zu aktivieren.
Beispiel: Verwenden Sie zum Protokollieren von Ergebnissen in einer Visual Studio Test Results File (TRX)
/Logger:trx
[; LogFileName=<Defaults to unique file name>]
LogFileName Verwenden Sie LogFilePrefix=<prefix> anstelle einer separaten, zeitstempelten Datei pro Ausführung. LogFileName legt einen expliziten Namen fest und überschreibt die vorherige Datei, aber LogFilePrefix nicht.
Weitere Informationen finden Sie im Protokollierungsbeispiel.
/ListTests:[Dateiname] Listet ermittelte Tests aus dem angegebenen Testcontainer auf. Kurzform: /lt.
Hinweis: Die option /TestCaseFilter hat keine Auswirkung beim Auflisten von Tests; es steuert nur, welche Tests ausgeführt werden.
/Blame Führt die Tests im Schuldzuweisungsmodus aus. Diese Option ist hilfreich beim Isolieren problematischer Tests, die dazu führen, dass der Testhost abstürzt. Wenn ein Absturz erkannt wird, wird in TestResults/<Guid>/<Guid>_Sequence.xml eine Sequenzdatei erstellt, die die Reihenfolge der Tests erfasst, die vor dem Absturz ausgeführt wurden.
Sie können auch ein Absturz- oder Hang-Dump sammeln, z /Blame:CollectDump;DumpType=full . B. oder /Blame:CollectHangDump;TestTimeout=90m;HangDumpType=mini. Die entsprechenden dotnet test Schalter sind --blame-crash und --blame-hang.
Die vollständigen Anforderungen an die Matrix und die Dumpsammlung finden Sie unter "Blame Data Collector".
/Diag:[Dateiname] Schreibt Diagnoseablaufverfolgungsprotokolle in die angegebene Datei.
Legen Sie die Ablaufverfolgungsebene mit /Diag:<file name>;tracelevel=<off\|error\|warning\|info\|verbose> (Standardeinstellung ist ) fest verbose.
/ResultsDirectory:[Pfad] Das Verzeichnis der Testergebnisse wird im angegebenen Pfad erstellt, falls nicht vorhanden.
Beispiel: /ResultsDirectory:<pathToResultsDirectory>
/ParentProcessId:[parentProcessId] Prozess-ID des übergeordneten Prozesses, der für den Start des aktuellen Prozesses verantwortlich ist.
/Port:[Port] Port für Socketverbindung und Empfangen der Ereignismeldungen.
/Collect:[dataCollector friendlyName] Aktiviert den Datensammler für die Testausführung. Weitere Informationen.
@[Datei] Liest zusätzliche Optionen aus der angegebenen Antwortdatei. Argumente in der Datei werden durch Leerzeichen (Leerzeichen oder Newlines) getrennt, und die Anführung wird unterstützt, sodass Optionen mehrere Zeilen umfassen können.
Beispiel: vstest.console.exe @options.rsp

Trinkgeld

Bei den Optionen und Werten wird die Groß-/Kleinschreibung nicht beachtet.

Beispiele

Die Syntax für die Ausführung von vstest.console.exe lautet:

vstest.console.exe [TestFileNames] [Options]

Standardmäßig gibt der Befehl "0" zurück, wenn er normal beendet wird, auch wenn keine Tests erkannt werden. Wenn Sie einen Wert ungleich Null zurückgeben möchten, wenn keine Tests ermittelt werden, verwenden Sie <TreatNoTestsAsError>true</TreatNoTestsAsError> Runsettings-Option.

Der folgende Befehl führt vstest.console.exe für die Testbibliothek myTestProject.dllaus:

vstest.console.exe myTestProject.dll

Der folgende Befehl führt vstest.console.exe mit mehreren Testdateien aus. Separate Testdateinamen mit Leerzeichen:

vstest.console.exe myTestFile.dll myOtherTestFile.dll

Der folgende Befehl führt vstest.console.exe mit mehreren Optionen aus. Sie führt die Tests in der myTestFile.dll Datei in einem isolierten Prozess aus und verwendet Einstellungen, die in der Datei "Local.RunSettings" angegeben sind. Darüber hinaus werden nur Tests ausgeführt, die als "Priority=1" gekennzeichnet sind, und die Ergebnisse werden in einer TRX- Datei protokolliert.

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

Der folgende Befehl führt vstest.console.exe mit der Option /blame für die Testbibliothek myTestProject.dllaus:

vstest.console.exe myTestFile.dll /blame

Wenn ein Testhostabsturz aufgetreten ist, wird die sequence.xml Datei generiert. Die Datei enthält vollqualifizierte Namen der Tests in ihrer Abfolge der Ausführung bis hin zu dem spezifischen Test, der zum Zeitpunkt des Absturzes ausgeführt wurde.

Wenn kein Testhostabsturz auftritt, wird die sequence.xml Datei nicht generiert.

Beispiel für eine generierte sequence.xml Datei:

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

In diesem Fall ist der <Test Name> letzte der Test, der zum Zeitpunkt des Absturzes ausgeführt wurde.

Exitcodes

vstest.console.exe gibt einen von zwei Ausgangscodes zurück:

Code Bedeutung
0 Erfolg. Der angeforderte Vorgang wurde abgeschlossen, und für eine Testausführung wurden alle ausgeführten Tests bestanden.
1 Versagen. Ein oder mehrere Tests sind beispielsweise fehlgeschlagen, ein Ausführungsfehler wurde gemeldet, die Befehlszeile war ungültig oder fehlt, eine Testquelle konnte nicht geladen werden, oder die Ausführung wurde abgebrochen oder abgebrochen.

Der Prozess gibt niemals einen anderen Wert zurück. Wenn Sie Tests dotnet testausführen, zeigt das .NET SDK einen Nicht-Null-Exitcode an, wenn die Ausführung auf die gleiche Weise fehlschlägt.

Wenn die Ermittlung keine übereinstimmenden Tests findet, gibt der Läufer eine Warnung anstelle eines Fehlers aus und gibt standardmäßig immer noch zurück 0. Wenn Sie stattdessen eine Ausführung ausführen möchten, die null Tests 1 erkennt oder auswählt, legen <TreatNoTestsAsError>true</TreatNoTestsAsError> Sie es im RunConfiguration-Element der RUNSETTINGS-Datei fest. Weitere Informationen finden Sie unter Konfigurieren von Komponententests mithilfe einer Runsettings-Datei.

Escapefilterausdrücke in der Shell

Ein /TestCaseFilter-Ausdruck wird sowohl von Ihrer Shell als auch von der Testplattform analysiert, sodass einige Zeichen shellspezifische Escapezeichen benötigen, bevor vstest.console.exe sie empfängt. Das Zitat des gesamten Ausdrucks, wie in den Beispielen weiter oben in diesem Artikel, vermeidet die meisten Probleme. Die folgenden Fälle benötigen zusätzliche Sorgfalt:

  • PowerShell: Das Komma (,) ist der Arrayoperator und das Semikolon (;) ist ein Anweisungstrennzeichen. Zitieren Sie den gesamten Filterausdruck so, dass er buchstäblich durchlaufen wird, z. B /TestCaseFilter:"FullyQualifiedName=MyNamespace.MyClass.MyMethod". .

  • Bash und zsh (Linux und macOS): Escape ! mit einem umgekehrten Schrägstrich, wenn Sie den !~ Operator (nicht enthält) verwenden, z --filter FullyQualifiedName\!~IntegrationTests . B. mit dotnet test. Auch Anführungszeichenwerte, die Zeichen mit besonderer Bedeutung für die Shell enthalten, z <. B. , >oder , in einer generischen Typargumentliste:

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

Die vollständige Filterreferenz und die unterstützten Eigenschaften pro Testframework finden Sie unter TestCase-Filter.

Beispiel für die Protokollierung

Jeder Logger definiert seine eigenen Parameter. Im Gegensatz zu trx können Sie mit dem Konsolenprotokollierer Ausführlichkeitsebene festlegen. Geben Sie VSTest.Console/? weitere Informationen an der Befehlszeile ein.

Hier ist ein Beispiel für den Konsolenprotokollierer:

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

Unterstützte Ausführlichkeitsstufen sind leise, minimal, normal und detailliert.

In PowerShell müssen Sie Anführungszeichen verwenden:

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

Eine vollständige Liste der verfügbaren Logger sowie Anweisungen zum Erstellen Ihres eigenen Loggers finden Sie unter Berichterstellungstestergebnisse im Vstest-Repository.

UWP-Beispiel

Für UWP muss auf die Appxrecipe-Datei anstelle einer DLL verwiesen werden.

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

Umgebungsvariablen

Die Testplattform erkennt mehrere Umgebungsvariablen. Im Folgenden finden Sie die nützlichsten, wenn Sie Tests über die Befehlszeile ausführen. Die vollständige Liste finden Sie unter Umgebungsvariablen, die von der Testplattform im Vstest-Repository verstanden werden.

Variable Beschreibung
VSTEST_CONNECTION_TIMEOUT Timeout in Sekunden zum Herstellen von Verbindungen zwischen Testplattformkomponenten (vstest.console.exe, Testhost und Datensammler). Der Standard ist 90. Erhöhen Sie sie auf langsamen Computern oder wenn die Netzwerklatenz zu Verbindungstimeouts führt.
VSTEST_DIAG Aktiviert die Diagnoseprotokollierung und gibt den Pfad zur Protokolldatei an. Entspricht der Option "/Diag ".
VSTEST_DIAG_VERBOSITY Legt die Ausführlichkeit der Diagnoseprotokollierung fest, wenn VSTEST_DIAG sie aktiviert ist. Gültige Werte sind Verbose, Info, Warning, und Error (Standard ist Verbose).
VSTEST_HOST_DEBUG Legen Sie diesen Wert auf einen beliebigen nicht leeren Wert fest, um das Debuggen des Testhost-Prozesses zu aktivieren.
VSTEST_RUNNER_DEBUG Legen Sie diesen Wert auf einen beliebigen wert, der nicht leer ist, um das Debuggen des Läufers zu aktivieren (vstest.console.exe).
VSTEST_DUMP_PATH Überschreibt das Standardverzeichnis, in dem Absturzabbilder gespeichert werden.
VSTEST_DUMP_FORCEPROCDUMP Legen Sie diesen Wert auf einen nicht leeren Wert fest, um zu erzwingen, dass ProcDump für die Absturzabbildsammlung verwendet wird.
VSTEST_DISABLE_UTF8_CONSOLE_ENCODING Legen Sie diese Einstellung fest, um die UTF-8-Codierung für die Konsolenausgabe zu 1 deaktivieren.
VSTEST_CONSOLE_PATH Pfad zur vstest.console.exe ausführbaren Datei, die von der Weiterleitungs-App des dotnet test .NET SDK verwendet wird. Entspricht dem -p:VSTestConsolePath , wenn Sie für ein Projekt ausgeführt werden dotnet test .

Verwandte Inhalte

  • Last updated on