Dela via

dotnet-test

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

Namn

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

beskrivning

Kommandot dotnet test bygger lösningen och kör testerna med antingen VSTest eller Microsoft Testing Platform (MTP). För att aktivera MTP måste du ange testkörare i global.json filen.

Några exempel på hur du anger testkörare i global.json filen:

{
    "test": {
        "runner": "Microsoft.Testing.Platform"
    }
}

{
    "test": {
        "runner": "VSTest"
    }
}

Viktigt!

Upplevelsen dotnet test för MTP stöds endast i Microsoft.Testing.Platform version 1.7 och senare.

Tips

Konceptuell dokumentation om dotnet testfinns i Testa med dotnet-test.

VSTest och Microsoft.Testing.Platform (MTP)

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>]
    [--disable-build-servers]
    [-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]
    [--tl:[auto|on|off]]
    [-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 med hjälp av VSTest. 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.

Kommentar

dotnet test ursprungligen utformades för att endast VSTeststödja -baserade testprojekt. De senaste versionerna av testramverken lägger till stöd för Microsoft.Testing.Platform. Den här alternativa testplattformen är enklare och snabbare än VSTest och stöder dotnet test med olika kommandoradsalternativ. Mer information finns i Microsoft.Testing.Platform.

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

Varning

När du använder Microsoft.Testing.Platformkan du läsa dotnet-testintegrering för de alternativ som stöds. Som tumregel stöds alla alternativ som inte är relaterade till testning medan varje testrelaterat alternativ inte stöds som det är.

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

  • --disable-build-servers

    Tvingar kommandot att ignorera alla beständiga byggservrar. Det här alternativet är ett konsekvent sätt att inaktivera all användning av cachelagring av versioner, vilket tvingar fram en version från grunden. En version som inte förlitar sig på cacheminnen är användbar när cacheminnena kan vara skadade eller felaktiga av någon anledning. Tillgänglig sedan .NET 7 SDK.

  • -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 skulle -v:detailed --consoleLoggerParameters:ErrorsOnly 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:

  • -t|--list-tests

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

  • --tl:[auto|on|off]

    Anger om Terminal Logger ska användas för byggutdata. Standardvärdet är auto, som först verifierar miljön innan du aktiverar terminalloggning. Miljökontrollen verifierar att terminalen kan använda moderna utdatafunktioner och inte använder en omdirigerad standardutdata innan den nya loggaren aktiveras. on hoppar över miljökontrollen och aktiverar terminalloggning. off hoppar över miljökontrollen och använder standardkonsolloggaren.

    TerminalLogger visar återställningsfasen följt av byggfasen. Under varje fas visas de pågående byggprojekten längst ned i terminalen. Varje projekt som skapar utdata både det MSBuild-mål som för närvarande skapas och hur lång tid som spenderas på det målet. Du kan söka efter den här informationen om du vill veta mer om bygget. När ett projekt är färdigt skrivs ett enda "build completed"-avsnitt som samlar in:

    • Namnet på det skapade projektet.
    • Målramverket (om det är flera mål).
    • Status för bygget.
    • Den primära utdatan för den versionen (som är hyperlänkad).
    • Diagnostik som genereras för projektet.

    Det här alternativet är tillgängligt från och med .NET 8.

  • -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 RunSettings-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 med Microsoft Code Coverage:

    dotnet test --collect "Code Coverage"

  • Kör testerna i projektet i den aktuella katalogen och generera en kodtäckningsfil med hjälp av Coverlet- (när du har installerat Coverlet-insamlarintegrering):

    dotnet test --collect:"XPlat 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

Information om filteralternativ

--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
  • Namn
  • Klassnamn
  • Prioritet
  • TestCategory
xUnit
  • Fullständigt kvalificerat namn
  • visningsnamn
  • Kategori
NUnit
  • Fullständigt kvalificerat namn
  • Namn
  • Kategori
  • Prioritet

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

Operatör 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:

Operatör 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.

Se även