dotnet-test med Microsoft.Testing.Platform (MTP)

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

Namn

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

Sammanfattning

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>]
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Description

Med MTP dotnet test fungerar snabbare än med VSTest. Testrelaterade argument är inte längre fasta eftersom de är knutna till de registrerade tilläggen i testet project(er). Dessutom stöder MTP ett globbningsfilter när du kör tester. Mer information finns i MTP.

Important

Tilläggsspecifika alternativ är inte inbyggda i MTP. Varje måltestprogram måste registrera tillägget som tillhandahåller ett alternativ. Lägg till tilläggets NuGet-paket direkt eller använd en test-SDK-konfiguration eller profil som innehåller paketet. Annars misslyckas testkörningen med slutkod 5 eftersom alternativet är okänt. Kör dotnet test --help för att se vilka alternativ som är tillgängliga för de valda testprogrammen och se Tilläggsalternativ efter scenario för att hitta paketet för ett alternativ.

Varning

När MTP har valts via global.jsonförväntar dotnet test sig alla testprojekt att använda MTP. Det är ett fel om något av testprojekten använder VSTest.

Versionskrav

MTP-läget dotnet test kräver .NET 10 SDK och MTP 1.7 eller senare. Alternativ som har lagts till efter .NET 10 har individuella SDK-versionskrav i följande avsnitt. Vissa alternativ kräver också ett nyare MTP-paket eftersom SDK:n samordnar den fullständiga körningen medan varje testprogram implementerar motsvarande funktion.

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 måste styra när återställningen sker.

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

Important

När du kör ett projekt eller en lösning med --no-restorebehåller du både det återställningsgenererade projekttillståndet obj i mappen och den matchande globala paketmappen. Importer av testramverk och plattformspaket anger de MSBuild-egenskaper som dotnet test används för att identifiera MTP-testprogram. Alternativet --no-build innebär --no-restoreockså . Om testmiljön innehåller byggda testprogram men inte tillståndet för projektåterställning använder du --test-modules i stället. Mer information finns i No test projects were found.

Options

Anmärkning

Du kan bara använda något av följande alternativ i taget: --project, --solution eller --test-modules. De här alternativen kan inte kombineras. När du använder --test-moduleskan du dessutom inte ange --arch, --configuration, , --device--framework, , --list-devices, --os, --runtimeeller --use-current-runtime. De här alternativen kräver projektutvärdering eller är inte relevanta för en redan inbyggd modul.

  • PROJECT_OR_TRAVERSAL_PATH

    Anger ett projekt eller traverseringsprojekt som ska köras. Från och med .NET 11 Förhandsversion 7, dotnet test stöder Microsoft.Build.Traversal projekt, till exempel dirs.proj, och kör rekursivt sina refererade testprojekt.

    Från och med .NET 12 Preview 1 kan argumentet även identifiera en C#-filbaserad MTP-testapp. Filbaserade testappar stöder --deviceinte .

  • --project <PROJECT_PATH>

    Anger sökvägen till den project fil som ska köras (mappnamn eller fullständig sökväg). Om det inte anges används den aktuella katalogen som standard.

  • --solution <SOLUTION_PATH>

    Anger sökvägen till lösningsfilen som ska köras (mappnamn eller fullständig sökväg). Om det inte anges används den aktuella katalogen som standard.

  • --test-modules <EXPRESSION>

    Filtrerar testmoduler med hjälp av filbläddring. Endast tester som hör till dessa testmoduler körs. Eftersom det här alternativet inte utvärderar projekt använder du det för att köra redan byggda testprogram när tillståndet för projektåterställning inte är tillgängligt. Från och med .NET 11 Förhandsversion 6 prefix ett mönster med ! för att utesluta matchande moduler. Avgränsa flera mönster med semikolon; tomt utrymme runt varje mönster ignoreras.

  • --root-directory <ROOT_PATH>

    Anger rotkatalogen för alternativet --test-modules. Den kan bara användas med alternativet --test-modules.

  • --max-parallel-test-modules <NUMBER>

    Anger det maximala antalet testmoduler som kan köras parallellt. Standardvärdet är Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Anger den konfigurationsfil som ska användas för testkörning. Om en relativ sökväg anges konverteras den till en absolut sökväg baserat på den aktuella katalogen. Mer information om konfigurationsfilinställningarna finns itestconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Anger den katalog där testresultat lagras. Om katalogen inte finns skapas den. Om en relativ sökväg anges konverteras den till en absolut sökväg baserat på den aktuella katalogen.

  • --results-directory-layout <flat|per-module>

    Anger hur en körning med flera moduler organiserar filer under resultatkatalogen. Standardvärdet , flat, skriver alla resultat till samma katalog. per-module skriver varje moduls resultat till <project>/<target-framework>_<runtime-or-architecture>, vilket förhindrar att rapporter med samma filnamn skriver över varandra.

    Tillgänglig från och med .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Anger katalogen där diagnostikutdata lagras. Om katalogen inte finns skapas den. Om en relativ sökväg anges konverteras den till en absolut sökväg baserat på den aktuella katalogen.

  • --minimum-expected-tests <NUMBER>

    Anger ett positivt minsta antal tester för hela körningen. Om det aggregerade testantalet är mindre än det angivna minimumet misslyckas testkörningen med slutkod 9. Det globala antalet inkluderar överhoppade tester. Mer information om slutkoder finns i MTP-slutkoder.

    Eftersom det här alternativet visas före --är det ett globalt alternativ (helkörning). Om du vill kräva ett minimum för varje testmodul i stället skickar du alternativet efter -- så att det vidarebefordras till varje testmodul. Mer information finns i Minimum för helkörning och per modul.

    Anmärkning

    Det globala minimumet kräver .NET 10 SDK (10.0.100) eller en senare version.

  • --maximum-failed-tests <NUMBER>

    Stoppar den fullständiga körningen när den når det angivna antalet misslyckade, felade, tidsgränserade eller avbrutna tester. Körningen avslutas med kod 13.

    Tillgänglig från och med .NET 11 Förhandsversion 7 och kräver MTP 2.4 eller senare.

  • --timeout <DURATION>

    Stoppar den fullständiga körningen efter den angivna varaktigheten medan minst ett testprogram körs. Ange ett positivt tal följt av en enhet, till exempel 500ms, 90s, 10m, 2heller 1d. En tidsgräns för körning avslutas med kod 3.

    Tillgänglig från och med .NET 11 Förhandsversion 7 och kräver MTP 2.4 eller senare.

  • -e|--environment <NAME="VALUE">

    Anger en miljövariabel för testprocessen. Ange alternativet flera gånger för att ange flera variabler. Kommandoradsvärden åsidosätter värden från en startprofil.

    Använd .NET SDK 10.0.110 eller senare när det inte finns någon startprofil eller när du anger --no-launch-profile. Tidigare .NET 10 SDK-versioner kan ignorera variablerna i dessa fall. Från och med .NET 11 Förhandsversion 7 flödar variablerna även till kapacitetsmedveten version, enhetsval, distribution och körningsargumentmål.

  • -a|--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. Det här alternativet och det angivna värdet måste uttryckligen överlappas i alla dotnet kommandon som är beroende av utdata från ett annat dotnet kommando, till exempel när du använder dotnet build --no-restore och dotnet publish --no-build. Tillgänglig sedan .NET 8 SDK.

    Tillgänglig för MTP-läge som börjar med .NET 11.

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

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

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

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

    Anmärkning

    Det går inte att köra tester för en lösning med en global RuntimeIdentifier egenskap (explicit eller via --arch, --runtimeeller --os). Ange RuntimeIdentifier på en enskild project nivå i stället.

  • --use-current-runtime|--ucr

    Använder den aktuella körningen som målkörning under återställning och bygge.

    Tillgänglig från och med .NET 11 Förhandsversion 6. Du kan inte kombinera det här alternativet med --test-modules.

  • -v|--verbosity <LEVEL>

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

  • --no-build

    Anger att testet project inte skapas innan det körs. Den anger också implicit flaggan --no-restore.

  • --no-dependencies

    Hoppar över att skapa projekt-till-projekt-referenser.

    Tillgänglig från och med .NET 11 Förhandsversion 6.

  • --no-restore

    Anger att en implicit återställning inte körs när kommandot körs.

  • --nologo|--no-logo|--no-banner

    Undertrycker .NET- och MTP-startbanderollerna. Formulären -nologo och /nologoDOTNET_NOLOGO miljövariabeln stöds också.

    Tillgänglig i MTP-läge från och med .NET 11 Förhandsversion 7.

  • --no-ansi

    Inaktiverar utdata från ANSI-escape-tecken till skärm.

  • --no-progress

    Inaktiverar rapporteringsstatus till skärm.

  • --no-artifact-post-processing

    Inaktiverar efterbearbetning av kompatibla artefakter efter en körning med flera moduler. Från och med .NET 11 RC 1 och MTP 2.4 kan registrerade artefakter efter processorer kombinera kompatibla rapporter, till exempel TRX-resultat. Om efterbearbetningen misslyckas bevarar SDK:n de ursprungliga artefakterna och testavslutskoden.

  • --output <VERBOSITY_LEVEL>

    Anger utdataverositeten för testresultat. Giltiga värden är Minimal, Normal och Detailed. Standardvärdet är Normal. Minimal kräver förhandsversion av MTP 2.4.

  • --show-test-results <OUTCOME>

    Väljer resultatblock efter utfall. I förhandsversionen av MTP 2.4 använder du passed, failed, skipped, all, eller none. Värdet failed innehåller även fel, tidsgränser och annulleringar.

    Kombinera passed, failedoch skipped med kommatecken, blanksteg eller upprepade --show-test-results alternativ. Kombinera all inte eller none med ett annat värde. Det här explicita alternativet åsidosätter förinställningen --output oavsett alternativordning.

  • --list-tests [text|json]

    Visar en lista över identifierade tester utan att köra dem. Utelämna värdet eller ange text för läsbara utdata. Från och med .NET 11 Förhandsversion 7 anger du json för ett versionshanterat JSON-dokument som grupperar tester efter sammansättning, målramverk och arkitektur och innehåller tillgängliga identifierare, källplatser, metoder, parametrar och egenskaper.

  • --no-launch-profile

    Försök inte att använda launchSettings.json för att konfigurera programmet. Används som standard launchSettings.json , vilket kan tillämpa miljövariabler och kommandoradsargument på det körbara testet.

  • --no-launch-profile-arguments

    Använd inte argument som anges av commandLineArgs i startprofilen för att köra programmet.

  • --device <DEVICE_ID>

    Väljer en enhet, emulator eller simulator för varje målramverk i ett Android- eller iOS-testprojekt. MTP-sökvägen stöder även macOS- och Mac Catalyst-testprojekt. Om indata är interaktiva och fler än en enhet är tillgänglig dotnet test kan du uppmana dig att välja en.

    Tillgänglig från och med .NET 11 Förhandsversion 6. För projekt med flera mål använder du .NET 11 RC 2 eller senare så att enhetsidentifiering utvärderar varje målramverk korrekt. Browser WebAssembly-testprojekt stöds inte av det här alternativet.

  • --list-devices

    Visar tillgängliga enheter för ett projekt utan att köra tester. Ange ett projekt i stället för en lösning.

    Tillgänglig från och med .NET 11 Förhandsversion 7.

  • --collect-test-map och --affected-tests

    Samla in en databastestkarta eller kör tester som påverkas av en ändring. Dessa experimentella alternativ kräver ett separat distribuerat tillägg och DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 miljövariabeln. Du kan inte kombinera de två alternativen. Arbetsflöden för berörda tester stöder inte heller enhetstestning, parallella testmoduler eller principer för lägsta test.

    Tillgänglig från och med .NET 11 RC 1.

  • --property:<NAME>=<VALUE>

    Anger en eller flera MSBuild-egenskaper. Ange flera egenskaper genom att upprepa alternativet:

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
    

    Det korta formuläret -p kan användas för --property. Detsamma gäller för /property:property=value och dess korta formulär är /p. Mer information om tillgängliga argument finns i dokumentationen för dotnet msbuild.

  • -?|-h|--help

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

  • args

    Anger extra argument som ska skickas till testprogram. Använd ett blanksteg för att separera flera argument. Mer information och exempel på vad som ska skickas finns i MTP-översikt och MTP-funktioner.

    Tips/Råd

    Om du vill ange extra argument för specifika projekt använder du egenskapen TestingPlatformCommandLineArguments MSBuild. Den här egenskapen är särskilt användbar när din lösning blandar testramverk (till exempel MSTest och xUnit.net) eller när endast vissa projekt refererar till ett visst tillägg. Mer information finns i Lösningar med blandade testramverk eller tillägg.

Anmärkning

Om du vill aktivera spårningsloggning till en fil använder du miljövariabeln DOTNET_CLI_TEST_TRACEFILE för att ange sökvägen till spårningsfilen.

Från och med .NET 11 RC 1 använder dotnet test -bl en MSBuild-session för flera projekt, flera mål och enhetskörningar så att den binära loggen innehåller den fullständiga versionen.

Beteende för utdata och annullering

Från och med .NET 11 Förhandsversion 6 visar interaktiva ANSI-utdata tester som för närvarande körs och rapporterar antal test per sammansättning. Förloppsvisningen förblir inaktiverad när utdata omdirigeras, ANSI- eller förloppsutdata inaktiveras eller miljön inte är interaktiv.

Från och med .NET 11 Förhandsversion 6 slutar den första Ctrl+C att schemalägga nya testprogram och begär att samarbetsavbokningen avbryts. Tryck på Ctrl+C igen för att avsluta de underordnade processerna omedelbart. En avbruten körning avslutas med kod 3.

Live test-host-utdata kräver en MTP-värd som stöder protokoll 1.1 eller senare. Äldre värdar håller utdata insamlade och spelar upp dem igen för en misslyckad modul. Från och med .NET 11 Förhandsversion 7 trunkerar felsammanfattningar insamlade standardutdata längre än 40 rader till de första 30 och sista 10 raderna. Diagnostikloggar behåller de fullständiga utdata.

För körningar dotnet test med flera moduler utvärderar nolltestresultatet för den fullständiga körningen som börjar med .NET 11 Preview 7. En modul utan tester misslyckas inte om en annan modul kör testerna, såvida inte en explicit princip för lägsta test kräver fler tester.

Resultat och artefakter

När utdatalayouten för SDK-artefakter är aktiverad .NET 11 RC 1 och senare versioner placerar MTP-rapporter, täckningsfiler och diagnostik under <ArtifactsPath>/test/<project>/<pivot> som standard. En explicit --results-directory eller --results-directory-layout har företräde.

Från och med .NET 11 RC 1 och MTP 2.4 kan kompatibla tillägg efterprocessartefakter från en körning med flera moduler. TRX-tillägget kan till exempel skapa en sammanslagen rapport samtidigt som rapporterna per modul bevaras. Tilläggs- och rapportkrav finns i MTP-testrapporter.

Vidarebefordra argument till testprogrammet

dotnet test vidarebefordrar en token som den inte känner igen till testprogrammet. När ett identifierat alternativ visas mellan ett okänt alternativnamn och dess värde, kan borttagning av det identifierade alternativet ändra hur de överblivna token binder till alternativ i testprogrammet. Undvik den här tvetydigheten genom att placera testprogramargument efter en literal --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

Föregående exempel kräver Microsoft.Testing.Extensions.TrxReport paketet, antingen som en direkt paketreferens eller via en test-SDK-konfiguration som innehåller det.

Samma parserbeteende gäller för dotnet run och dotnet build. Ett detaljerat exempel finns i Vidarebefordra argument till programmet i referensen dotnet run .

Miniminivåer för helkörning och per modul

-- För --minimum-expected-testsavgör avgränsaren alternativets omfång:

  • Argumenten tidigare-- är globala. Orkestratorn dotnet test tolkar dem för hela körningen.
  • Argument efter-- är lokala. dotnet test vidarebefordrar dem till varje testmodul, så att varje modul tillämpar dem separat.

Eftersom --minimum-expected-tests är tillgängligt i båda omfången kan du kräva ett minimum för hela körningen, för varje modul eller båda:

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

Föregående kommando kräver minst 5 tester för hela körningen och minst 2 tester i varje testmodul.

De två omfången räknar överhoppade tester på olika sätt:

Scope Räknas överhoppade tester mot minimivärdet?
Global Yes. Den dotnet test aggregerade summan inkluderar överhoppade tester.
Per modul No. MTP exkluderar överhoppade tester från antalet tester som kördes.

Från och med .NET 11 SDK bestäms nolltestutfallet för hela körningen en gång från de aggregerade resultaten. En modul som inte matchar några tester, till exempel på grund av --test-modules eller en global --filter, avslutas med kod 8 (ZeroTests), men den koden normaliseras till att lyckas innan resultaten aggregeras. Därför misslyckas inte en enda tom modul hela körningen, även om modulen behåller sin Exit code: 8 diagnostik i utdata för synlighet.

MTP 4.3.0 och senare versioner tillhandahåller --zero-tests-policy <allow-skipped|strict>. Med standardvärdet , allow-skippedkan en modul som hoppas över lyckas. Värdet strict behandlar överhoppade tester som inte körs, så en överhoppad modul avslutas med kod 8. Skicka alternativet efter -- för att vidarebefordra det till varje testmodul:

dotnet test -- --zero-tests-policy strict

När du inte anger ett globalt minimum avgör .NET 11 SDK hela nolltestutfallet separat. En helt överhoppad hel körning avslutas med kod 8 oavsett värdet per modul --zero-tests-policy .

När du anger --minimum-expected-tests och minimivärdet inte uppfylls misslyckas körningen med slutkod 9 (MinimumExpectedTestsPolicyViolation). Den här koden skiljer sig från 8 så att ett striktare globalt minimum eller minimum per modul inte förväxlas med en tom modul. För ett minimum per modul för att returnera kod 9 när modulen kör noll tester måste testmodulen använda MTP 4.4.0 eller en senare version.

Anmärkning

--minimum-expected-tests 0 är ogiltigt. Om du vill utelämna slutkoden för nolltester använder du --ignore-exit-code 8.

Från och med .NET 11 Förhandsversion 6, --tl, --terminalloggeroch --tlp vidarebefordras till MSBuild i stället för testprogrammet. Från och med .NET 12 Förhandsversion 1 vidarebefordras även de identifierade -mt formulären och -multiThreaded formulären till MSBuild. Om du vill skicka ett programalternativ med något av dessa namn placerar du det efter --.

Skicka körningslägesalternativ som --help och --list-tests direkt till dotnet test. Från och med .NET 11 Förhandsversion 6 verifierar SDK körningsläget som förhandlats fram med testprogrammet. Om en startprofil eller TestingPlatformCommandLineArguments matar in något av dessa alternativ matchar inte den begärda SDK-åtgärden och programåtgärden, och körningen misslyckas med en diagnostik.

Examples

  • Kör testerna i project eller lösningen i den aktuella katalogen:

    dotnet test
    
  • Kör testerna i TestProject project:

    dotnet test --project ./TestProject/TestProject.csproj
    
  • Kör testerna i den TestProjects lösningen:

    dotnet test --solution ./TestProjects/TestProjects.sln
    
  • Kör testerna med hjälp av TestProject.dll sammansättning:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"
    
  • Kör testerna med hjälp av TestProject.dll sammansättning med rotkatalogen:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"
    
  • Kör alla testprojekt som refereras av ett bläddreringsprojekt med .NET 11 Förhandsversion 7 eller senare:

    dotnet test dirs.proj
    
  • Lista tester som JSON med .NET 11 Förhandsversion 7 eller senare:

    dotnet test --list-tests json
    
  • Kör en C#-filbaserad MTP-testapp med .NET 12 Förhandsversion 1 eller senare:

    dotnet test App.Tests.cs
    
  • Kör testerna i den aktuella katalogen med tillägget Microsoft Code Coverage. Testprogrammet måste referera till Microsoft.Testing.Extensions.CodeCoverage, antingen direkt eller via en test-SDK-konfiguration som innehåller den:

    dotnet test --coverage
    
  • Kör testerna och lagra resultaten i en specifik katalog:

    dotnet test --results-directory ./TestResults
    
  • Kör testerna med diagnostiska utdata i en specifik katalog:

    dotnet test --diagnostic-output-directory ./Diagnostics
    
  • Kör testerna så att minst 10 tester körs:

    dotnet test --minimum-expected-tests 10
    
  • Kräv minst 5 tester under hela körningen och minst 2 tester i varje testmodul:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2
    
  • Kör testerna i argumentet TestProject project och ange argumentet -bl (binär logg) till msbuild:

    dotnet test --project ./TestProject/TestProject.csproj -bl
    
  • Kör testerna i egenskapen TestProject project och ange egenskapen MSBuild DefineConstants till DEV:

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"
    

Se även