dotnet-test

Artikel
04/06/2024

Den här artikeln gäller för: ✔️ .NET Core 3.1 SDK och senare versioner

Name

dotnet test – .NET-testdrivrutin som används för att köra enhetstester.

Sammanfattning

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [--test-adapter-path <ADAPTER_PATH>]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [--blame]
    [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>]
    [--blame-crash-collect-always]
    [--blame-hang]
    [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>]
    [-f|--framework <FRAMEWORK>]
    [-e|--environment <NAME="VALUE">]
    [--filter <EXPRESSION>]
    [--interactive]
    [-l|--logger <LOGGER>]
    [--no-build]
    [--nologo]
    [--no-restore]
    [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>]
    [--results-directory <RESULTS_DIR>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>]
    [-t|--list-tests]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

beskrivning

Kommandot dotnet test används för att köra enhetstester i en viss lösning. Kommandot dotnet test skapar lösningen och kör ett testvärdprogram för varje testprojekt i lösningen. Testvärden kör tester i det angivna projektet med hjälp av ett testramverk, till exempel MSTest, NUnit eller xUnit, och rapporterar lyckade eller misslyckade tester. Om alla tester lyckas returnerar testlöparen 0 som slutkod. annars returneras 1 om ett test misslyckas.

För projekt med flera mål körs tester för varje målramverk. Testvärden och enhetstestramverket paketeras som NuGet-paket och återställs som vanliga beroenden för projektet. Från och med .NET 9 SDK körs dessa tester parallellt som standard. Om du vill inaktivera parallell körning anger du TestTfmsInParallel egenskapen MSBuild till false. Mer information finns i Köra tester parallellt och exempelkommandoraden senare i den här artikeln.

Testprojekt anger testkörare med ett vanligt <PackageReference> element, enligt följande exempelprojektfil:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
    <PackageReference Include="xunit" Version="2.8.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.1" />
  </ItemGroup>

</Project>

Var Microsoft.NET.Test.Sdk är testvärden, xunit är testramverket. Och xunit.runner.visualstudio är ett testkort som gör att xUnit-ramverket kan fungera med testvärden.

Implicit återställning

Du behöver inte köra dotnet restore eftersom den körs implicit av alla kommandon som kräver en återställning, till exempel dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishoch dotnet pack. Om du vill inaktivera implicit återställning använder du alternativet --no-restore .

Kommandot dotnet restore är fortfarande användbart i vissa scenarier där det är meningsfullt att uttryckligen återställa, till exempel kontinuerliga integreringsversioner i Azure DevOps Services eller i byggsystem som uttryckligen behöver styra när återställningen sker.

Information om hur du hanterar NuGet-feeds finns i dokumentationendotnet restore.

Nedladdningar av arbetsbelastningsmanifest

När du kör det här kommandot initieras en asynkron bakgrundsnedladdning av annonseringsmanifest för arbetsbelastningar. Om nedladdningen fortfarande körs när det här kommandot är klart stoppas nedladdningen. Mer information finns i Annonseringsmanifest.

Argument

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Sökväg till testprojektet.
- Sökväg till lösningen.
- Sökväg till en katalog som innehåller ett projekt eller en lösning.
- Sökväg till ett testprojekt .dll fil.
- Sökväg till ett testprojekt .exe fil.
Om den inte anges är effekten densamma som när argumentet används DIRECTORY för att ange den aktuella katalogen.

Alternativ

Varning

Icke-bakåtkompatibla ändringar i alternativ:

Från och med .NET 7: växla -a till alias --arch i stället för --test-adapter-path
Från och med .NET 7: växla -r till alias --runtime i stället för --results-directory

--test-adapter-path <ADAPTER_PATH>

Sökväg till en katalog som ska sökas efter ytterligare testkort. Endast .dll filer med suffix .TestAdapter.dll kontrolleras. Om det inte anges genomsöks katalogen för test .dll .

Kort formulär -a som är tillgängligt i .NET SDK-versioner tidigare än 7.

--arch <ARCHITECTURE>

Anger målarkitekturen. Det här är en kortsyntax för att ange Körtidsidentifierare (RID) där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --arch x86 till exempel RID till win-x86. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6 Förhandsversion 7.

--artifacts-path <ARTIFACTS_DIR>

Alla build-utdatafiler från det körda kommandot kommer att gå i undermappar under den angivna sökvägen, avgränsade med projekt. Mer information finns i Artefaktutdatalayout. Tillgänglig sedan .NET 8 SDK.

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

Det här alternativet skapar inte en minnesdump och är inte användbart när testet hänger sig.
--blame-crash (Tillgängligt sedan .NET 5.0 SDK)

Kör testerna i skuldläge och samlar in en kraschdump när testvärden oväntat avslutas. Det här alternativet beror på vilken version av .NET som används, typen av fel och operativsystemet.

För undantag i hanterad kod samlas en dump automatiskt in på .NET 5.0 och senare versioner. Den genererar en dump för testhost eller någon underordnad process som också kördes på .NET 5.0 och kraschade. Krascher i intern kod genererar ingen dump. Det här alternativet fungerar i Windows, macOS och Linux.

Kraschdumpar i inbyggd kod, eller när du använder .NET Core 3.1 eller tidigare versioner, kan bara samlas in i Windows med hjälp av Procdump. En katalog som innehåller procdump.exe och procdump64.exe måste finnas i path- eller PROCDUMP_PATH miljövariabeln. Ladda ned verktygen. Antyder --blame.

Om du vill samla in en kraschdump från ett internt program som körs på .NET 5.0 eller senare kan användningen av Procdump tvingas genom att miljövariabeln anges VSTEST_DUMP_FORCEPROCDUMP till 1.
--blame-crash-dump-type <DUMP_TYPE> (Tillgängligt sedan .NET 5.0 SDK)

Vilken typ av kraschdump som ska samlas in. Dumptyper som stöds är full (standard) och mini. Antyder --blame-crash.
--blame-crash-collect-always (Tillgängligt sedan .NET 5.0 SDK)

Samlar in en kraschdump på förväntat samt oväntad testvärdavslutning.
--blame-hang (Tillgängligt sedan .NET 5.0 SDK)

Kör testerna i skuldläge och samlar in en låsningsdump när ett test överskrider den angivna tidsgränsen.
--blame-hang-dump-type <DUMP_TYPE> (Tillgängligt sedan .NET 5.0 SDK)

Vilken typ av kraschdump som ska samlas in. Det ska vara full, minieller none. När none har angetts avslutas testvärden vid tidsgränsen, men ingen dump samlas in. Antyder --blame-hang.
--blame-hang-timeout <TIMESPAN> (Tillgängligt sedan .NET 5.0 SDK)

Tidsgränsen per test, varefter en låsningsdump utlöses och testvärdprocessen och alla dess underordnade processer dumpas och avslutas. Tidsgränsvärdet anges i något av följande format:
- 1.5h, 1.5hour, 1.5hours
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000millisecond, 5400000millisekunder
När ingen enhet används (till exempel 5400000) antas värdet vara i millisekunder. När det används tillsammans med datadrivna tester beror tidsgränsbeteendet på det testkort som används. För xUnit, NUnit. och MSTest 2.2.4+ förnyas tidsgränsen efter varje testfall. För MSTest före version 2.2.4 används tidsgränsen för alla testfall. Det här alternativet stöds i Windows med netcoreapp2.1 och senare, i Linux med netcoreapp3.1 och senare, och på macOS med net5.0 eller senare. Antyder --blame och --blame-hang.

-c|--configuration <CONFIGURATION>

Definierar byggkonfigurationen. Standardvärdet för de flesta projekt är Debug, men du kan åsidosätta konfigurationsinställningarna för bygget i projektet.

--collect <DATA_COLLECTOR_NAME>

Aktiverar datainsamlare för testkörningen. Mer information finns i Övervaka och analysera testkörning.

Du kan till exempel samla in kodtäckning med hjälp av alternativet --collect "Code Coverage" . Mer information finns i Använda kodtäckning, Anpassa kodtäckningsanalys och GitHub-problem dotnet/docs#34479.

Om du vill samla in kodtäckning kan du också använda Coverlet med hjälp av alternativet --collect "XPlat Code Coverage" .
-d|--diag <LOG_FILE>

Aktiverar diagnostikläge för testplattformen och skriver diagnostikmeddelanden till den angivna filen och till filer bredvid den. Processen som loggar meddelandena avgör vilka filer som skapas, till exempel *.host_<date>.txt för testvärdloggen och *.datacollector_<date>.txt för datainsamlarloggen.
-e|--environment <NAME="VALUE">

Anger värdet för en miljövariabel. Skapar variabeln om den inte finns, åsidosätter om den finns. Om du använder det här alternativet framtvingar du att testerna körs i en isolerad process. Alternativet kan anges flera gånger för att tillhandahålla flera variabler.
-f|--framework <FRAMEWORK>

Målramverkets moniker (TFM) för målramverket som ska köras tester för. Målramverket måste också anges i projektfilen.
--filter <EXPRESSION>

Filtrerar tester i det aktuella projektet med det angivna uttrycket. Endast tester som matchar filteruttrycket körs. Mer information finns i avsnittet Filteralternativinformation . Mer information och exempel på hur du använder selektiv enhetstestfiltrering finns i Köra selektiva enhetstester.

-?|-h|--help

Skriver ut en beskrivning av hur du använder kommandot.

--interactive

Tillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen. Tillgänglig sedan .NET Core 3.0 SDK.

-l|--logger <LOGGER>

Anger en loggare för testresultat och valfritt växlar för loggaren. Ange den här parametern flera gånger för att aktivera flera loggare. Mer information finns i Rapportera testresultat, Växlar för loggare och exemplen senare i den här artikeln.

För att kunna skicka kommandoradsväxlar till loggern:
- Använd det fullständiga namnet på växeln, inte det förkortade formuläret (till exempel verbosity i stället för v).
- Utelämna inledande bindestreck.
- Ersätt utrymmet som avgränsar varje växel med ett semikolon ;.
- Om växeln har ett värde ersätter du kolonavgränsaren mellan växeln och dess värde med likhetstecknet =.
Till exempel -v:detailed --consoleLoggerParameters:ErrorsOnly skulle bli verbosity=detailed;consoleLoggerParameters=ErrorsOnly.
--no-build

Skapar inte testprojektet innan det körs. Den anger --no-restore också implicit flaggan.
--nologo

Kör tester utan att visa Microsoft TestPlatform-banderollen. Tillgänglig sedan .NET Core 3.0 SDK.
--no-restore

Kör inte en implicit återställning när kommandot körs.
-o|--output <OUTPUT_DIRECTORY>

Katalog där binärfilerna ska köras. Om det inte anges är ./bin/<configuration>/<framework>/standardsökvägen . För projekt med flera målramverk (via TargetFrameworks egenskapen) måste du också definiera --framework när du anger det här alternativet. dotnet test kör alltid tester från utdatakatalogen. Du kan använda AppDomain.BaseDirectory för att använda testtillgångar i utdatakatalogen.
- .NET 7.0.200 SDK och senare
  
  Om du anger --output alternativet när du kör det här kommandot på en lösning genererar CLI en varning (ett fel i 7.0.200) på grund av den oklara semantiken i utdatasökvägen. Alternativet --output är inte tillåtet eftersom alla utdata från alla inbyggda projekt kopieras till den angivna katalogen, som inte är kompatibel med flera målprojekt, samt projekt som har olika versioner av direkta och transitiva beroenden. Mer information finns i Alternativet på lösningsnivå --output är inte längre giltigt för build-relaterade kommandon.

--os <OS>

Anger måloperativsystemet (OS). Det här är en kortsyntax för att ange Körtidsidentifierare (RID) där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --os linux till exempel RID till linux-x64. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6.

--results-directory <RESULTS_DIR>

Katalogen där testresultaten ska placeras. Om den angivna katalogen inte finns skapas den. Standardvärdet finns TestResults i katalogen som innehåller projektfilen.

Kort formulär -r som är tillgängligt i .NET SDK-versioner tidigare än 7.
-r|--runtime <RUNTIME_IDENTIFIER>

Målkörningen som ska testas för.

Kort formulär -r tillgängligt från och med .NET SDK 7.
-s|--settings <SETTINGS_FILE>

Filen .runsettings som ska användas för att köra testerna. Elementet TargetPlatform (x86|x64) har ingen effekt för dotnet test. Om du vill köra tester som är avsedda för x86 installerar du x86-versionen av .NET Core. Biten i dotnet.exe som finns på sökvägen är vad som ska användas för att köra tester. Mer information finns i följande resurser:
- Konfigurera enhetstester med hjälp av en .runsettings fil.
- Konfigurera en testkörning
-t|--list-tests

Visa en lista över identifierade tester i stället för att köra testerna.

-v|--verbosity <LEVEL>

Anger kommandots verbositetsnivå. Tillåtna värden är q[uiet], m[inimal], n[ormal], d[etailed]och diag[nostic]. Standardvärdet är minimal. Mer information finns i LoggerVerbosity.

args

Anger extra argument som ska skickas till adaptern. Använd ett blanksteg för att separera flera argument.

Listan över möjliga argument beror på det angivna beteendet:
- När du anger ett projekt, en lösning eller en katalog, eller om du utelämnar det här argumentet, vidarebefordras anropet till msbuild. I så fall finns de tillgängliga argumenten i dokumentationen för dotnet msbuild.
- När du anger en .dll eller en .exe vidarebefordras anropet till vstest. I så fall finns de tillgängliga argumenten i dotnet vstest-dokumentationen.
RunSettings Argument

RunSettings Infogade skickas som de sista argumenten på kommandoraden efter "-- " (observera utrymmet efter --). RunSettings Infogade anges som [name]=[value] par. Ett blanksteg används för att separera flera [name]=[value] par.

Exempel: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Mer information finns i Skicka körning Inställningar argument via kommandoraden.

Exempel

Kör testerna i projektet i den aktuella katalogen:
```
dotnet test
```

Kör testerna test1 i projektet:

dotnet test ~/projects/test1/test1.csproj

Kör testerna med hjälp av test1.dll sammansättning:
```
dotnet test ~/projects/test1/bin/debug/test1.dll
```
Kör testerna i projektet i den aktuella katalogen och generera en testresultatfil i trx-format:
```
dotnet test --logger trx
```
Kör testerna i projektet i den aktuella katalogen och generera en kodtäckningsfil (efter installationen av Coverlet-insamlarens integrering):
```
dotnet test --collect:"XPlat Code Coverage"
```
Kör testerna i projektet i den aktuella katalogen och generera en kodtäckningsfil (endast Windows):
```
dotnet test --collect "Code Coverage"
```
Kör testerna i projektet i den aktuella katalogen och logga med detaljerad utförlighet till konsolen:
```
dotnet test --logger "console;verbosity=detailed"
```
Kör testerna i projektet i den aktuella katalogen och logga med trx-loggaren för att testaResults.trx i mappen TestResults :
```
dotnet test --logger "trx;logfilename=testResults.trx"
```
Eftersom loggfilens namn har angetts används samma namn för varje målramverk när det gäller ett projekt med flera mål. Utdata för varje målramverk skriver över utdata för föregående målramverk. Filen skapas i mappen TestResults i testprojektmappen, eftersom relativa sökvägar är relativa till den mappen. I följande exempel visas hur du skapar en separat fil för varje målramverk.
Kör testerna i projektet i den aktuella katalogen och logga med trx-loggaren till filer i mappen TestResults , med filnamn som är unika för varje målramverk:
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
Kör testerna i projektet i den aktuella katalogen och logga med html-loggaren för att testResults.html i mappen TestResults :
```
dotnet test --logger "html;logfilename=testResults.html"
```
Kör testerna i projektet i den aktuella katalogen och rapportera tester som pågick när testvärden kraschade:
```
dotnet test --blame
```
Kör testerna test1 i projektet och ange -bl argumentet (binär logg) till msbuild:
```
dotnet test ~/projects/test1/test1.csproj -bl
```
Kör testerna test1 i projektet och ange egenskapen MSBuild DefineConstants till DEV:
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
Kör testerna test1 i projektet och ange egenskapen MSBuild TestTfmsInParallel till false:
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--filter <EXPRESSION>

<Expression> har formatet <property><operator><value>[|&<Expression>].

<property> är ett attribut för Test Case. Följande är de egenskaper som stöds av populära enhetstestramverk:

Test Framework	Egenskaper som stöds
MSTest	Fullständigt kvalificerat namn Name ClassName Prioritet TestCategory
xUnit	Fullständigt kvalificerat namn DisplayName Category
Nunit	Fullständigt kvalificerat namn Name Kategori Prioritet

<operator> Beskriver relationen mellan egenskapen och värdet:

Operator	Funktion
`=`	Exakt matchning
`!=`	Inte exakt matchning
`~`	Innehåller
`!~`	Innehåller inte

<value> är en sträng. Alla sökningar är skiftlägesokänsliga.

Ett uttryck utan en <operator> betraktas automatiskt som en contains på-egenskap FullyQualifiedName (till exempel dotnet test --filter xyz är samma som dotnet test --filter FullyQualifiedName~xyz).

Uttryck kan kopplas till villkorsstyrda operatorer:

Operator	Funktion
`\|`	ELLER
`&`	OCH

Du kan omsluta uttryck i parenteser när du använder villkorsstyrda operatorer (till exempel (Name~TestMethod1) | (Name~TestMethod2)).

Mer information och exempel på hur du använder selektiv enhetstestfiltrering finns i Köra selektiva enhetstester.

Dela via