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 alle 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.
| 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,testMethod2Die /Tests Befehlszeilenoption 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. |
| /Enablecodecoverage | Aktiviert codeCoverage des Datendiagnoseadapters in der Testausführung. Standardeinstellungen werden verwendet, wenn sie nicht mithilfe der Einstellungsdatei angegeben werden. |
| /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. |
| /UseVsixExtensions | Mit dieser Option wird der vstest.console.exe Prozess verwendet oder die installierten VSIX-Erweiterungen (sofern vorhanden) in der Testausführung übersprungen. Diese Option ist veraltet. Ab der nächsten Hauptversion von Visual Studio kann diese Option entfernt werden. Wechseln Sie zu verbrauchenden Erweiterungen, die als NuGet-Paket zur Verfügung gestellt wurden. Beispiel: /UseVsixExtensions:true |
| /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 Plattform anstelle der Plattform, die von der aktuellen Laufzeit bestimmt wird. Diese Option kann nur x86- und x64-Plattformen unter Windows erzwingen. Die ARM-Option ist unterbrochen und führt zu x64 auf den meisten Systemen. Geben Sie diese Option NICHT an, die auf Laufzeiten ausgeführt werden soll, die sich nicht in der Liste der gültigen Werte wie ARM64 befinden. Gültige Werte sind x86, x64 und ARM. |
| /Framework: [Framework-Version] | .NET-Zielversion, die für die Testausführung verwendet werden soll. Beispielwerte sind Framework35, Framework40, Framework45, FrameworkUap10, .NETCoreApp,Version=v1.1.TargetFrameworkAttribute wird verwendet, um diese Option automatisch aus Der Assembly zu erkennen, und standardmäßig wird 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:framework40 |
| /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. |
| /? | 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>] |
| /ListTests:[Dateiname] | Listet ermittelte Tests aus dem angegebenen Testcontainer auf. Hinweis: Die option /TestCaseFilters hat keine Auswirkung beim Auflisten von Tests; es steuert nur, welche Tests ausgeführt werden. |
| /ListDiscoverers | Listet installierte Test-Discoverer auf. |
| /ListExecutors | Listet installierte Testausführer auf. |
| /ListLoggers | Listet installierte Testlogger auf. |
| /ListSettingsProviders | Listet installierte Testeinstellungsanbieter auf. |
| /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. Weitere Informationen finden Sie unter Datensammler. |
| /Diag:[Dateiname] | Schreibt Diagnoseablaufverfolgungsprotokolle in die angegebene Datei. |
| /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. |
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>
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