Befehlszeilenoptionen für VSTest.Console.exe
VSTest.Console.exe ist das Befehlszeilentool für die Ausführung von Tests. Sie können in der Befehlszeile verschiedene Optionen in beliebiger Reihenfolge angeben. Diese Optionen werden unter Allgemeine Befehlszeilenoptionen aufgeführt.
Hinweis
Der MSTest-Adapter in Visual Studio funktioniert aus Kompatibilitätsgründen auch im Legacymodus (entspricht dem Ausführen von Tests mit mstest.exe). Im Legacymodus kann er die TestCaseFilter-Funktion nicht nutzen. Der Adapter kann in den Legacymodus wechseln, wenn eine TESTSETTINGS-Datei angegeben wird, forcelegacymode in einer RUNSETTINGS-Datei auf TRUE festgelegt ist oder Attribute wie HostType verwendet werden.
Sie müssen VSTest.Console.exe für die Durchführung automatisierter Tests auf einem auf der ARM-Architektur basierenden Computer verwenden.
Öffnen Sie die Developer-Eingabeaufforderung, um das Befehlszeilentool zu verwenden. Sie können es aber auch über den Pfad %Program Files(x86)%\Microsoft Visual Studio\<version>\<edition>\common7\ide\CommonExtensions\<Platform | Microsoft> öffnen.
Allgemeine Befehlszeilenoptionen
In der folgenden Tabelle werden sämtliche Optionen für VSTest.Console.exe mit einer kurzen Beschreibung aufgeführt. Durch Eingabe von VSTest.Console/? in eine Befehlszeile wird eine ähnliche Zusammenfassung ausgegeben.
| Option | Beschreibung |
|---|---|
| [Testdateinamen] | Führt Tests auf Grundlage der angegebenen Dateien aus. Trennt mehrere Testdateinamen durch Leerzeichen. Beispiele: mytestproject.dll, mytestproject.dll myothertestproject.exe |
| /Settings: [Dateiname] | Führen Sie Tests mit zusätzlichen Einstellungen wie Datensammlern aus. Weitere Informationen hierzu finden Sie unter Konfigurieren von Komponententests mithilfe einer RUNSETTINGS-Datei. Ein Beispiel: /Settings:local.runsettings |
| /Tests: [Testname] | Führt Tests aus, die mit den eingegebenen Werten übereinstimmen. Dieser Befehl führt einen Vergleich mit dem vollständigen Testnamen durch, einschließlich Namespace. Um mehrere Werte bereitzustellen, trennen Sie diese durch Kommas. Ein Beispiel: /Tests:TestMethod1,testMethod2Die Befehlszeilenoption /Tests kann nicht zusammen mit der Befehlszeilenoption /TestCaseFilter verwendet werden. |
| /Parallel | Gibt an, dass die Tests parallel ausgeführt werden. Standardmäßig können alle verfügbaren Kerne auf dem Computer verwendet werden. Die Anzahl der zu verwendenden Kerne kann mithilfe einer Einstellungsdatei konfiguriert werden. |
| /Enablecodecoverage | Aktiviert den CodeCoverage-Datendiagnoseadapter im Testlauf. Die Standardeinstellungen werden verwendet, wenn keine Einstellungsdatei angegeben wurde. |
| /InIsolation | Führt die Tests in einem isolierten Prozess aus. Durch diese Isolation ist die Wahrscheinlichkeit, dass der vstest.console.exe-Prozess bei Testfehlern beendet wird, weniger hoch, die Tests werden jedoch möglicherweise langsamer ausgeführt. |
| /UseVsixExtensions | Durch diese Option werden in dem vstest.console.exe-Prozess die VSIX-Erweiterungen verwendet oder übersprungen, die im Testlauf (ggf.) installiert wurden. Diese Option ist veraltet. Ab der nächsten Hauptversion von Visual Studio ist diese Option möglicherweise nicht mehr verfügbar. Fahren Sie mit der Verarbeitung der Erweiterungen fort, die in Form eines NuGet-Pakets verfügbar gemacht wurden. Ein Beispiel: /UseVsixExtensions:true |
| /TestAdapterPath:[Pfad] | Erzwingt, dass der vstest.console.exe-Prozess im Testlauf (ggf.) benutzerdefinierte Testadapter aus einem angegebenen Pfad verwendet. Ein Beispiel: /TestAdapterPath:[pathToCustomAdapters] |
| /Platform:[Plattformtyp] | Erzwingt die Verwendung der angegebenen Plattform anstelle der Plattform, die von der aktuellen Runtime vorgegeben wird. Mit dieser Option können nur x86- und x64-Plattformen unter Windows erzwungen werden. Die ARM-Option funktioniert nicht und läuft in den meisten Systemen auf x64 hinaus. Führen Sie diese Option NICHT in Runtimes aus, die nicht in der Liste der gültigen Werte enthalten sind, z. B. ARM64. Gültige Werte sind x86, x64 und ARM. |
| /Framework: [Frameworkversion] | .NET-Zielversion, die für die Testausführung verwendet werden soll. Beispielwerte: Framework35, Framework40, Framework45, FrameworkUap10, .NETCoreApp,Version=v1.1.„TargetFrameworkAttribute“ wird verwendet, um diese Option automatisch in Ihrer Assembly zu ermitteln. Wenn das Attribut nicht vorhanden ist, lautet der Standardwert Framework40. Diese Option muss explizit angegeben werden, wenn TargetFrameworkAttribute aus Ihren .NET Core-Assemblys entfernt wird.Wenn als Zielframework Framework35 angegeben ist, werden die Tests in CLR 4.0 im „Kompatibilitätsmodus“ ausgeführt. Ein Beispiel: /Framework:framework40 |
| /TestCaseFilter:[Ausdruck] | Führt Tests aus, die mit dem angegebenen Ausdruck übereinstimmen. <Expression> ist vom Format <property>=<value>[|<Expression>]. Ein Beispiel: /TestCaseFilter:"Priority=1"Ein Beispiel: /TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"Die Befehlszeilenoption /TestsCaseFilter kann nicht zusammen 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 eine Protokollierung für die Testergebnisse an. Geben Sie den Parameter mehrmals an, um mehrere Protokollierungen zu ermöglichen. Beispiel: Wenn die Ergebnisse in einer TRX-Datei (Visual Studio Text Results) protokolliert werden sollen, geben Sie Folgendes an: /Logger: TRX [;LogFileName=<der Standardwert ist der eindeutige Dateiname>] |
| /ListTests:[Dateiname] | Listet gefundene Tests aus dem angegebenen Testcontainer auf. Hinweis: Die /TestCaseFilters Option hat keine Auswirkung beim Auflisten von Tests; sie steuert nur, welche Tests ausgeführt werden. |
| /ListDiscoverers | Listet alle installierten Test-Discoverer auf. |
| /ListExecutors | Listet alle installierten Test-Executors auf. |
| /ListLoggers | Listet alle installierten Testprotokollierungen auf. |
| /ListSettingsProviders | Listet alle installierten Testeinstellungsanbieter auf. |
| /Blame | Führt die Tests im blame-Modus aus. Diese Option hilft beim Isolieren von fehlerhaften Tests, die den Absturz des Testhosts verursachen. 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 Datensammlung mit /Blame. |
| /Diag:[Dateiname] | Schreibt Protokolle zur Diagnoseablaufverfolgung für die angegebene Datei. |
| /ResultsDirectory:[path] | Das Verzeichnis mit den Testergebnissen wird am angegebenen Pfad erstellt, falls es noch nicht vorhanden ist. Ein Beispiel: /ResultsDirectory:<pathToResultsDirectory> |
| /ParentProcessId:[parentProcessId] | Prozess-ID des übergeordneten Prozesses, der für den Start des aktuellen Prozesses verantwortlich ist. |
| /Port:[port] | Der Port für die Socketverbindung und den Empfang der Ereignismeldungen. |
| /Collect:[dataCollector friendlyName] | Aktiviert den Datensammler für den Testlauf. Weitere Informationen. |
Tipp
Bei den Optionen und Werten muss die Groß-/Kleinschreibung nicht beachtet werden.
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 ermittelt werden. Wenn ein Wert ungleich 0 (null) zurückgegeben werden soll, wenn keine Tests ermittelt werden, verwenden Sie die runsettings-Option <TreatNoTestsAsError>true</TreatNoTestsAsError>.
Mit dem folgenden Befehl wird vstest.console.exe für die Bibliothek myTestProject.dll ausgeführt:
vstest.console.exe myTestProject.dll
Mit dem folgenden Befehl wird vstest.console.exe mit mehreren Testdateien ausgeführt. Trennt Testdateinamen durch Leerzeichen:
vstest.console.exe myTestFile.dll myOtherTestFile.dll
Mit dem folgenden Befehl wird vstest.console.exe mit verschiedenen Optionen ausgeführt. Die Tests werden in der Datei myTestFile.dll in einem isolierten Prozess ausgeführt. Zudem werden Einstellungen verwendet, die in der Datei Local.RunSettings angegeben sind. Darüber hinaus werden mit dem Befehl nur Tests ausgeführt, die mit „Priorität = 1“ gekennzeichnet sind. Die Ergebnisse werden in einer TRX-Datei protokolliert.
vstest.console.exe myTestFile.dll /Settings:Local.RunSettings /InIsolation /TestCaseFilter:"Priority=1" /Logger:trx
Mit dem folgenden Befehl wird vstest.console.exe mit der Option /blame für die Bibliothek myTestProject.dll ausgeführt:
vstest.console.exe myTestFile.dll /blame
Wenn ein Testhost abstürzt, wird die Datei sequence.xml generiert. Die Datei enthält die vollqualifizierten Namen der Tests in Reihenfolge ihrer Ausführung bis einschließlich des Tests, der zum Zeitpunkt des Absturzes ausgeführt wurde.
Wenn der Testhost nicht abstürzt, wird die Datei sequence.xml nicht generiert.
Hier sehen Sie ein Beispiel für die Datei 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>
UWP-Beispiel
Bei UWP muss auf die APPXRECIPE-Datei anstelle einer DLL-Datei verwiesen werden.
vstest.console.exe /Logger:trx /Platform:x64 /framework:frameworkuap10 UnitTestsUWP\bin\x64\Release\UnitTestsUWP.build.appxrecipe