VSTest.Console.exe kommandoradsalternativ

VSTest.Console.exe är kommandoradsverktyget för att köra tester. Du kan ange flera alternativ i valfri ordning på kommandoraden. De här alternativen visas i Allmänna kommandoradsalternativ.

Not

MSTest-adaptern i Visual Studio fungerar också i äldre läge (motsvarar att köra tester med mstest.exe) för kompatibilitet. I äldre läge kan den inte dra nytta av funktionen TestCaseFilter. Adaptern kan växla till äldre läge när en testsettings fil anges, forcelegacymode är inställd på true i en -körningar fil, eller med hjälp av attribut som HostType.

Om du vill köra automatiserade tester på en ARM-arkitekturbaserad dator måste du använda VSTest.Console.exe.

Öppna Kommandotolken för utvecklare om du vill använda kommandoradsverktyget, eller så hittar du verktyget i %Program Files(x86)%\Microsoft Visual Studio\<version>\<edition>\common7\ide\CommonExtensions\<Platform | Microsoft>.

Allmänna kommandoradsalternativ

I följande tabell visas de vanligaste alternativen för VSTest.Console.exe och korta beskrivningar av dem. Du kan se en liknande sammanfattning genom att skriva VSTest.Console/? på en kommandorad. Fullständig referens, inklusive interna och äldre växlar som inte visas här, finns ivstest.console.exe kommandoradsalternativ och specifikt Utelämnade växlar i vstest-lagringsplatsen.

Alternativ Beskrivning
[testfilnamn] Kör tester från de angivna filerna. Avgränsa flera testfilnamn med blanksteg.
Exempel: mytestproject.dll, mytestproject.dll myothertestproject.exe
/Settings:[filnamn] Kör tester med ytterligare inställningar, till exempel datainsamlare. Mer information finns i Konfigurera enhetstester med hjälp av en .runsettings-fil
Exempel: /Settings:local.runsettings
/Tests:[testnamn] Kör tester med namn som innehåller de angivna värdena. Det här kommandot matchar det fullständiga testnamnet, inklusive namnområdet. Om du vill ange flera värden avgränsar du dem med kommatecken.
Exempel: /Tests:TestMethod1,testMethod2
Kommandoradsalternativet /Tests kan inte användas med kommandoradsalternativet /TestCaseFilter .
/Parallel Anger att testerna ska köras parallellt. Som standard kan upp till alla tillgängliga kärnor på datorn användas. Du kan konfigurera antalet kärnor som ska användas i en inställningsfil.
/InIsolation Kör testerna i en isolerad process.
Den här isoleringen gör vstest.console.exe processen mindre sannolikt att stoppas vid ett fel i testerna, men testerna kan köras långsammare.
/TestAdapterPath:[sökväg] Tvingar vstest.console.exe att använda anpassade testkort från en angiven sökväg (om någon) i testkörningen.
Exempel: /TestAdapterPath:[pathToCustomAdapters]
/Platform:[plattformstyp] Tvingar den angivna plattformsarkitekturen att användas i stället för den plattform som bestäms av den aktuella körningen. Värden är skiftlägesokänsliga. de godkända värdena är x86, x64, ARM, ARM64, S390x, Ppc64le, RiscV64och LoongArch64.
På Windows kan endast x86 och x64 tvingas på ett tillförlitligt sätt, vilket ARM anger resultat i x64 på de flesta system. Ange inte det här alternativet för körning på en körning som inte finns i listan med giltiga värden.
/Framework: [framework version] Den .NET-målversion som ska användas för testkörning.
Moderna ramverks korta formulär accepteras och parsas av NuGet framework-parsern, till exempel net48, net6.0eller net10.0 (samt de långa formerna som .NETFramework,Version=v4.8 och .NETCoreApp,Version=v10.0).
De äldre aliasen Framework35, Framework40, Framework45, FrameworkCore10och FrameworkUap10 accepteras också.
TargetFrameworkAttribute används för att automatiskt identifiera det här alternativet från sammansättningen och standardvärdet Framework40 är när attributet inte finns. Du måste uttryckligen ange det här alternativet om du tar bort TargetFrameworkAttribute- från dina .NET Core-sammansättningar.
Om målramverket anges som Framework35körs testerna i CLR 4.0 "kompatibilitetsläge".
Exempel: /Framework:net8.0
/TestCaseFilter:[uttryck] Kör tester som matchar det angivna uttrycket.
<Expression> har formatet <egenskap>=<värdet>[|<Expression>].
Exempel: /TestCaseFilter:"Priority=1"
Exempel: /TestCaseFilter:"TestCategory=Nightly|FullyQualifiedName=Namespace.ClassName.MethodName"
Kommandoradsalternativet /TestCaseFilter kan inte användas med kommandoradsalternativet /Tests .
Information om hur du skapar och använder uttryck finns i TestCase-filter. När du skriver ett filter direkt i ett gränssnitt kan du läsa Escape-filteruttryck i gränssnittet.
/Environment:[NAME]=[VALUE] Anger värdet för en miljövariabel för testvärdprocessen. Skapar variabeln om den inte finns och åsidosätter den om den gör det. Det här alternativet innebär /InIsolation och tvingar testerna att köras i en isolerad process. Ange alternativet flera gånger för att ange flera variabler. Kort formulär: /e.
Exempel: /e:VARIABLE1=VALUE1
/? Visar användningsinformation.
/Logger:[uri/friendlyname] Ange en logger för testresultat. Ange parametern flera gånger för att aktivera flera loggare.
Exempel: Om du vill logga in resultat i en Visual Studio-testresultatfil (TRX) använder du
/Logger:trx
[; LogFileName=<Standardinställningar för unikt filnamn>]
Använd LogFilePrefix=<prefix> i stället för LogFileName att behålla en separat, tidsstämpelfil per körning. LogFileName anger ett explicit namn och skriver över den tidigare filen, medan LogFilePrefix den inte gör det.
Mer information finns i loggningsexemplet.
/ListTests:[filnamn] Visar en lista över identifierade tester från den angivna testcontainern. Kort formulär: /lt.
Obs! Alternativet /TestCaseFilter har ingen effekt när testerna visas. den styr bara vilka tester som körs.
/Blame Kör testerna i skuldläge. Det här alternativet är användbart när du isolerar problematiska tester som gör att testvärden kraschar. När en krasch identifieras skapar den en sekvensfil i TestResults/<Guid>/<Guid>_Sequence.xml som samlar in ordningen på tester som kördes före kraschen.
Du kan också samla in en krasch- eller låsningsdump, till exempel /Blame:CollectDump;DumpType=full eller /Blame:CollectHangDump;TestTimeout=90m;HangDumpType=mini. Motsvarande dotnet test växlar är --blame-crash och --blame-hang.
Den fullständiga alternativmatrisen och kraven för dumpinsamling finns i Skylla på datainsamlaren.
/Diag:[filnamn] Skriver diagnostikspårningsloggar till den angivna filen.
Ange spårningsnivån med /Diag:<file name>;tracelevel=<off\|error\|warning\|info\|verbose> (standardvärdet är verbose).
/ResultsDirectory:[sökväg] Testresultatkatalogen skapas i den angivna sökvägen om den inte finns.
Exempel: /ResultsDirectory:<pathToResultsDirectory>
/ParentProcessId:[parentProcessId] Process-ID för den överordnade processen som ansvarar för att starta den aktuella processen.
/Port:[port] Porten för socketanslutning och mottagning av händelsemeddelanden.
/Collect:[dataCollector friendlyName] Aktiverar datainsamlare för testkörningen. Mer information.
@[file] Läser ytterligare alternativ från den angivna svarsfilen. Argument i filen avgränsas med blanksteg (blanksteg eller nya rader) och citattecken stöds, så alternativ kan sträcka sig över flera rader.
Exempel: vstest.console.exe @options.rsp

Dricks

Alternativen och värdena är inte skiftlägeskänsliga.

Exempel

Syntaxen för att köra vstest.console.exe är:

vstest.console.exe [TestFileNames] [Options]

Som standard returnerar kommandot 0 när det avslutas normalt, även om inga tester identifieras. Om du vill returnera ett värde som inte är noll om inga tester identifieras använder du alternativet <TreatNoTestsAsError>true</TreatNoTestsAsError> körningar.

Följande kommando kör vstest.console.exe för testbiblioteket myTestProject.dll:

vstest.console.exe myTestProject.dll

Följande kommando kör vstest.console.exe med flera testfiler. Avgränsa testfilnamn med blanksteg:

vstest.console.exe myTestFile.dll myOtherTestFile.dll

Följande kommando kör vstest.console.exe med flera alternativ. Den kör testerna i filen myTestFile.dll i en isolerad process och använder inställningar som anges i filen Local.RunSettings. Dessutom körs bara tester märkta "Priority=1" och loggar resultatet till en .trx- fil.

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

Följande kommando kör vstest.console.exe med alternativet /blame för testbiblioteket myTestProject.dll:

vstest.console.exe myTestFile.dll /blame

Om en testvärdkrasch inträffade genereras sequence.xml-filen. Filen innehåller fullständigt kvalificerade namn på testerna i deras körningssekvens fram till och med det specifika test som kördes vid tidpunkten för kraschen.

Om det inte finns någon testvärdkrasch genereras inte densequence.xml filen.

Exempel på en genererad sequence.xml fil:

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

I det här fallet är det <Test Name> senaste testet som kördes vid tidpunkten för kraschen.

Utgångskoder

vstest.console.exe returnerar en av två slutkoder:

Kod Meaning
0 Framgång. Den begärda åtgärden slutfördes och för en testkörning godkändes alla utförda tester.
1 Fel. Till exempel misslyckades ett eller flera tester, ett körningsfel rapporterades, kommandoraden var ogiltig eller saknades, en testkälla kunde inte läsas in eller körningen avbröts eller avbröts.

Processen returnerar aldrig något annat värde. När du kör tester via dotnet testvisar .NET SDK en slutkod som inte är noll när körningen misslyckas på samma sätt.

När identifieringen inte hittar några matchande tester skriver löparen ut en varning i stället för ett fel och returnerar 0som standard fortfarande . Om du vill göra en körning som identifierar eller väljer noll tester returnerar 1 du i stället <TreatNoTestsAsError>true</TreatNoTestsAsError> i elementet RunConfiguration i .runsettings-filen . Mer information finns i Konfigurera enhetstester med hjälp av en .runsettings-fil.

Escape-filteruttryck i gränssnittet

Ett /TestCaseFilter-uttryck parsas av både gränssnittet och testplattformen, så vissa tecken behöver shell-specifik undflyende innan vstest.console.exe tar emot dem. Att citera hela uttrycket, som i exemplen tidigare i den här artikeln, undviker de flesta problem. Följande fall behöver extra försiktighet:

  • PowerShell: Kommatecknet (,) är matrisoperatorn och semikolonet (;) är en instruktionsavgränsare. Citera hela filteruttrycket så att det skickas igenom bokstavligen, till exempel /TestCaseFilter:"FullyQualifiedName=MyNamespace.MyClass.MyMethod".

  • Bash och zsh (Linux och macOS): Escape ! med ett omvänt snedstreck när du använder operatorn !~ (innehåller inte), till exempel --filter FullyQualifiedName\!~IntegrationTests med dotnet test. Citera även värden som innehåller tecken med särskild betydelse för gränssnittet, till exempel <, >eller , i en argumentlista av allmän typ:

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

Fullständig filtreringsreferens och egenskaper som stöds per testramverk finns i TestCase-filtret.

Loggningsexempel

Varje loggare definierar sina egna parametrar. Till skillnad från trx kan du med konsolloggaren ange utförlighetsnivå. Om du vill ha mer information skriver du VSTest.Console/? på kommandoraden.

Här är ett exempel för konsolloggaren:

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

Utförlighetsnivåer som stöds är tysta, minimala, normala och detaljerade.

I PowerShell måste du använda citattecken:

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

En fullständig lista över tillgängliga loggare samt instruktioner för att redigera din egen loggning finns i Rapportera testresultat på vstest-lagringsplatsen.

UWP-exempel

För UWP måste appxrecipe-filen refereras i stället för en DLL.

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

Miljövariabler

Testplattformen identifierar flera miljövariabler. Följande är de som är mest användbara när du kör tester från kommandoraden. Den fullständiga listan finns i Miljövariabler som testplattformen förstår på vstest-lagringsplatsen.

Variable Beskrivning
VSTEST_CONNECTION_TIMEOUT Timeout, i sekunder, för att upprätta anslutningar mellan testplattformskomponenter (vstest.console.exe, testhost och datainsamlare). Standardvärdet är 90. Öka den på långsamma datorer eller när nätverksfördröjning orsakar tidsgränser för anslutning.
VSTEST_DIAG Aktiverar diagnostikloggning och anger sökvägen till loggfilen. Motsvarar alternativet /Diag .
VSTEST_DIAG_VERBOSITY Anger verbositeten för diagnostikloggning när VSTEST_DIAG är aktiverad. Giltiga värden är Verbose, Info, Warningoch Error (standardvärdet är Verbose).
VSTEST_HOST_DEBUG Ange till valfritt värde som inte är tomt för att aktivera felsökning av testhost-processen.
VSTEST_RUNNER_DEBUG Ange till valfritt värde som inte är tomt för att aktivera felsökning av löparen (vstest.console.exe).
VSTEST_DUMP_PATH Åsidosätter standardkatalogen där feldumpar lagras.
VSTEST_DUMP_FORCEPROCDUMP Ange till valfritt värde som inte är tomt för att tvinga ProcDump att användas för insamling av kraschdumpar.
VSTEST_DISABLE_UTF8_CONSOLE_ENCODING Ange till för att 1 inaktivera inställningen UTF-8-kodning för konsolutdata.
VSTEST_CONSOLE_PATH Sökväg till vstest.console.exe körbar fil som används av .NET SDK:s vidarebefordringsappdotnet test. -p:VSTestConsolePath Motsvarar när du kör dotnet test ett projekt.

Relaterat innehåll

  • Last updated on