dotnet-test
Dit artikel is van toepassing op: ✔️ .NET Core 3.1 SDK en latere versies
dotnet test
- .NET-teststuurprogramma dat wordt gebruikt om eenheidstests uit te voeren.
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
De dotnet test
opdracht wordt gebruikt om eenheidstests uit te voeren in een bepaalde oplossing. De dotnet test
opdracht bouwt de oplossing en voert een testhosttoepassing uit voor elk testproject in de oplossing met behulp van VSTest
. De testhost voert tests uit in het opgegeven project met behulp van een testframework, bijvoorbeeld: MSTest, NUnit of xUnit, en rapporteert het slagen of mislukken van elke test. Als alle tests zijn geslaagd, retourneert de testloper 0 als afsluitcode; als een test mislukt, wordt 1 geretourneerd.
Notitie
dotnet test
oorspronkelijk ontworpen ter ondersteuning van alleen VSTest
op -gebaseerde testprojecten. Recente versies van de testframeworks voegen ondersteuning toe voor Microsoft.Testing.Platform. Dit alternatieve testplatform is lichtgewicht en sneller dan VSTest
en ondersteunt dotnet test
met verschillende opdrachtregelopties. Zie Microsoft.Testing.Platform voor meer informatie.
Voor projecten met meerdere doelgroepen worden tests uitgevoerd voor elk doelframework. De testhost en het eenheidstestframework zijn verpakt als NuGet-pakketten en worden hersteld als gewone afhankelijkheden voor het project. Vanaf de .NET 9 SDK worden deze tests standaard parallel uitgevoerd. Als u parallelle uitvoering wilt uitschakelen, stelt u de TestTfmsInParallel
eigenschap MSBuild in op false
. Zie Tests parallel uitvoeren en de voorbeeldopdrachtregel verderop in dit artikel voor meer informatie.
Testprojecten geven de testloper op met behulp van een gewoon <PackageReference>
element, zoals te zien is in het volgende voorbeeldprojectbestand:
<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>
Waar Microsoft.NET.Test.Sdk
is de testhost, xunit
is het testframework. En xunit.runner.visualstudio
is een testadapter, waarmee het xUnit-framework kan werken met de testhost.
U hoeft niet uit te voeren dotnet restore
omdat deze impliciet wordt uitgevoerd door alle opdrachten waarvoor een herstelbewerking moet worden uitgevoerd, zoals dotnet new
, dotnet build
, , dotnet run
, dotnet test
, , en dotnet publish
.dotnet pack
Als u impliciete herstel wilt uitschakelen, gebruikt u de --no-restore
optie.
De dotnet restore
opdracht is nog steeds nuttig in bepaalde scenario's waarbij het expliciet herstellen zinvol is, zoals builds voor continue integratie in Azure DevOps Services of in buildsystemen die expliciet moeten worden beheerd wanneer de herstelbewerking plaatsvindt.
Zie de dotnet restore
documentatie voor informatie over het beheren van NuGet-feeds.
Wanneer u deze opdracht uitvoert, wordt er een asynchrone achtergronddownload van reclamemanifesten voor workloads gestart. Als het downloaden nog steeds wordt uitgevoerd wanneer deze opdracht is voltooid, wordt het downloaden gestopt. Zie Reclamemanifesten voor meer informatie.
PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Pad naar het testproject.
- Pad naar de oplossing.
- Pad naar een map die een project of oplossing bevat.
- Pad naar een testproject .dll bestand.
- Pad naar een testproject .exe bestand.
Als dit niet is opgegeven, is het effect hetzelfde als het gebruik van het
DIRECTORY
argument om de huidige map op te geven.
Waarschuwing
Belangrijke wijzigingen in opties:
- Vanaf .NET 7: overschakelen
-a
naar alias--arch
in plaats van--test-adapter-path
- Vanaf .NET 7: overschakelen
-r
naar alias--runtime
in plaats van--results-directory
Waarschuwing
Raadpleeg bij gebruik Microsoft.Testing.Platform
de dotnet-testintegratie voor de ondersteunde opties. Als vuistregel wordt elke optie die niet gerelateerd is aan testen ondersteund, terwijl elke testgerelateerde optie niet wordt ondersteund.
--test-adapter-path <ADAPTER_PATH>
Pad naar een map die moet worden gezocht naar extra testadapters. Alleen .dll bestanden met achtervoegsel
.TestAdapter.dll
worden gecontroleerd. Als dit niet is opgegeven, wordt de map van de test -.dll doorzocht.Korte vorm
-a
beschikbaar in .NET SDK-versies ouder dan 7.
--arch <ARCHITECTURE>
Hiermee geeft u de doelarchitectuur. Dit is een verkorte syntaxis voor het instellen van de Runtime-id (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een
win-x64
computer opgeeft--arch x86
, wordt de RID ingesteld opwin-x86
. Als u deze optie gebruikt, gebruikt u de-r|--runtime
optie niet. Beschikbaar sinds .NET 6 Preview 7.
--artifacts-path <ARTIFACTS_DIR>
Alle builduitvoerbestanden van de uitgevoerde opdracht worden weergegeven in submappen onder het opgegeven pad, gescheiden door project. Zie De indeling Artefacten-uitvoer voor meer informatie. Beschikbaar sinds .NET 8 SDK.
--blame
Voert de tests uit in de schuldmodus. Deze optie is handig bij het isoleren van problematische tests waardoor de testhost vastloopt. Wanneer er een crash wordt gedetecteerd, wordt er een reeksbestand gemaakt waarin
TestResults/<Guid>/<Guid>_Sequence.xml
de volgorde wordt vastgelegd van tests die vóór de crash zijn uitgevoerd.Deze optie maakt geen geheugendump en is niet handig wanneer de test vasthangt.
--blame-crash
(Beschikbaar sinds .NET 5.0 SDK)Voert de tests uit in de foutmodus en verzamelt een crashdump wanneer de testhost onverwacht wordt afgesloten. Deze optie is afhankelijk van de versie van .NET die wordt gebruikt, het type fout en het besturingssysteem.
Voor uitzonderingen in beheerde code wordt automatisch een dump verzameld op .NET 5.0 en latere versies. Er wordt een dump gegenereerd voor testhost of een onderliggend proces dat ook is uitgevoerd op .NET 5.0 en is vastgelopen. Crashes in systeemeigen code genereren geen dump. Deze optie werkt in Windows, macOS en Linux.
Crashdumps in systeemeigen code of wanneer u .NET Core 3.1 of eerdere versies gebruikt, kunnen alleen worden verzameld in Windows met behulp van Procdump. Een map met procdump.exe en procdump64.exe moet zich in de omgevingsvariabele PATH of PROCDUMP_PATH bevinden. Download de hulpprogramma's. Impliceert
--blame
.Als u een crashdump wilt verzamelen van een systeemeigen toepassing die wordt uitgevoerd op .NET 5.0 of hoger, kan het gebruik van Procdump worden geforceerd door de
VSTEST_DUMP_FORCEPROCDUMP
omgevingsvariabele in te stellen op1
.--blame-crash-dump-type <DUMP_TYPE>
(Beschikbaar sinds .NET 5.0 SDK)Het type crashdump dat moet worden verzameld. Ondersteunde dumptypen zijn
full
(standaard) enmini
. Impliceert--blame-crash
.--blame-crash-collect-always
(Beschikbaar sinds .NET 5.0 SDK)Hiermee wordt een crashdump verzameld bij de verwachte en onverwachte afsluit van de testhost.
--blame-hang
(Beschikbaar sinds .NET 5.0 SDK)Voer de tests uit in de foutmodus en verzamelt een vastlopend dump wanneer een test de opgegeven time-out overschrijdt.
--blame-hang-dump-type <DUMP_TYPE>
(Beschikbaar sinds .NET 5.0 SDK)Het type crashdump dat moet worden verzameld. Het moet zijn
full
,mini
ofnone
. Wanneernone
dit is opgegeven, wordt de testhost beëindigd bij time-out, maar er wordt geen dump verzameld. Impliceert--blame-hang
.--blame-hang-timeout <TIMESPAN>
(Beschikbaar sinds .NET 5.0 SDK)Time-out per test, waarna een hangdump wordt geactiveerd en het testhostproces en alle onderliggende processen worden gedumpt en beëindigd. De time-outwaarde wordt opgegeven in een van de volgende indelingen:
- 1,5 uur, 1,5 uur, 1,5 uur
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400 sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000milliseconden, 5400000milliseconden
Wanneer er geen eenheid wordt gebruikt (bijvoorbeeld 5400000), wordt uitgegaan van een waarde in milliseconden. Bij gebruik in combinatie met gegevensgestuurde tests is het time-outgedrag afhankelijk van de gebruikte testadapter. Voor xUnit, NUnit. en MSTest 2.2.4+, de time-out wordt na elke testcase vernieuwd. Voor MSTest vóór versie 2.2.4 wordt de time-out gebruikt voor alle testcases. Deze optie wordt ondersteund in Windows met
netcoreapp2.1
en hoger, in Linux metnetcoreapp3.1
en hoger en in macOS metnet5.0
of hoger. Impliceert--blame
en--blame-hang
.
-c|--configuration <CONFIGURATION>
Definieert de buildconfiguratie. De standaardinstelling voor de meeste projecten is
Debug
, maar u kunt de buildconfiguratie-instellingen in uw project overschrijven.
--collect <DATA_COLLECTOR_NAME>
Hiermee schakelt u gegevensverzamelaar in voor de testuitvoering. Zie Testuitvoering bewaken en analyseren voor meer informatie.
U kunt bijvoorbeeld codedekking verzamelen met behulp van de
--collect "Code Coverage"
optie. Zie Codedekking gebruiken, Analyse van codedekking aanpassen en Dotnet/docs#34479 van GitHub-probleem gebruiken.Als u codedekking wilt verzamelen, kunt u Coverlet ook gebruiken met behulp van de
--collect "XPlat Code Coverage"
optie.-d|--diag <LOG_FILE>
Hiermee schakelt u de diagnostische modus voor het testplatform in en schrijft u diagnostische berichten naar het opgegeven bestand en naar bestanden ernaast. Het proces waarmee de berichten worden vastgelegd, bepaalt welke bestanden worden gemaakt, zoals
*.host_<date>.txt
voor het testhostlogboek en*.datacollector_<date>.txt
voor het logboek van de gegevensverzamelaar.-e|--environment <NAME="VALUE">
Hiermee stelt u de waarde van een omgevingsvariabele in. Hiermee maakt u de variabele als deze niet bestaat, overschrijft deze als deze bestaat. Met deze optie worden de tests geforceerd uitgevoerd in een geïsoleerd proces. De optie kan meerdere keren worden opgegeven om meerdere variabelen op te geven.
-f|--framework <FRAMEWORK>
Het doelframework moniker (TFM) van het doelframework om tests voor uit te voeren. Het doelframework moet ook worden opgegeven in het projectbestand.
--filter <EXPRESSION>
Filtert tests in het huidige project met behulp van de opgegeven expressie. Alleen tests die overeenkomen met de filterexpressie worden uitgevoerd. Zie de sectie Details van filteropties voor meer informatie. Zie Selectief eenheidstests uitvoeren voor meer informatie en voorbeelden over het gebruik van selectief eenheidstests.
-?|-h|--help
Hiermee wordt een beschrijving afgedrukt van het gebruik van de opdracht.
--interactive
Hiermee kan de opdracht stoppen en wachten op invoer of actie van de gebruiker. Bijvoorbeeld om de verificatie te voltooien. Beschikbaar sinds .NET Core 3.0 SDK.
-l|--logger <LOGGER>
Hiermee geeft u een logger voor testresultaten en optioneel schakelopties voor de logger. Geef deze parameter meerdere keren op om meerdere logboekregistraties in te schakelen. Zie Testresultaten rapporteren, Switches voor loggers en de voorbeelden verderop in dit artikel voor meer informatie.
Als u opdrachtregelswitches wilt doorgeven aan de logboekregistratie:
- Gebruik de volledige naam van de schakeloptie, niet het afgekorte formulier (bijvoorbeeld
verbosity
in plaats vanv
). - Laat alle voorloopstreepjes weg.
- Vervang de ruimte die elke schakelaar scheidt door een puntkomma
;
. - Als de schakeloptie een waarde heeft, vervangt u het dubbele puntscheidingsteken tussen die schakeloptie en de bijbehorende waarde door het gelijkteken
=
.
Zo zou
-v:detailed --consoleLoggerParameters:ErrorsOnly
bijvoorbeeldverbosity=detailed;consoleLoggerParameters=ErrorsOnly
worden.- Gebruik de volledige naam van de schakeloptie, niet het afgekorte formulier (bijvoorbeeld
--no-build
Het testproject wordt niet gebouwd voordat het wordt uitgevoerd. De vlag wordt ook impliciet ingesteld
--no-restore
.--nologo
Voer tests uit zonder de banner microsoft TestPlatform weer te geven. Beschikbaar sinds .NET Core 3.0 SDK.
--no-restore
Voert geen impliciete herstelbewerking uit bij het uitvoeren van de opdracht.
-o|--output <OUTPUT_DIRECTORY>
Map waarin de binaire bestanden moeten worden uitgevoerd. Als dit niet is opgegeven, is
./bin/<configuration>/<framework>/
het standaardpad . Voor projecten met meerdere doelframeworks (via deTargetFrameworks
eigenschap) moet u ook definiëren--framework
wanneer u deze optie opgeeft.dotnet test
voert altijd tests uit vanuit de uitvoermap. U kunt testassets gebruiken AppDomain.BaseDirectory in de uitvoermap..NET 7.0.200 SDK en hoger
Als u de optie opgeeft bij het
--output
uitvoeren van deze opdracht op een oplossing, verzendt de CLI een waarschuwing (een fout in 7.0.200) vanwege de onduidelijke semantiek van het uitvoerpad. De--output
optie is niet toegestaan omdat alle uitvoer van alle gemaakte projecten wordt gekopieerd naar de opgegeven map, die niet compatibel is met projecten met meerdere doelgroepen, evenals projecten met verschillende versies van directe en transitieve afhankelijkheden. Zie De optie Op oplossingsniveau--output
is niet meer geldig voor build-gerelateerde opdrachten voor meer informatie.
--os <OS>
Hiermee geeft u het doelbesturingssysteem (OS). Dit is een verkorte syntaxis voor het instellen van de Runtime-id (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een
win-x64
computer opgeeft--os linux
, wordt de RID ingesteld oplinux-x64
. Als u deze optie gebruikt, gebruikt u de-r|--runtime
optie niet. Beschikbaar sinds .NET 6.
--results-directory <RESULTS_DIR>
De map waar de testresultaten worden geplaatst. Als de opgegeven map niet bestaat, wordt deze gemaakt. De standaardwaarde bevindt zich
TestResults
in de map die het projectbestand bevat.Korte vorm
-r
beschikbaar in .NET SDK-versies ouder dan 7.-r|--runtime <RUNTIME_IDENTIFIER>
De doelruntime om op te testen.
Korte vorm
-r
beschikbaar vanaf .NET SDK 7.-s|--settings <SETTINGS_FILE>
Het
.runsettings
bestand dat moet worden gebruikt voor het uitvoeren van de tests. HetTargetPlatform
element (x86|x64) heeft geen effect voordotnet test
. Als u tests wilt uitvoeren die zijn gericht op x86, installeert u de x86-versie van .NET Core. De bitness van de dotnet.exe die zich op het pad bevindt, is wat wordt gebruikt voor het uitvoeren van tests. Voor meer informatie raadpleegt u de volgende bronnen:-t|--list-tests
Vermeld de gedetecteerde tests in plaats van de tests uit te voeren.
-v|--verbosity <LEVEL>
Hiermee stelt u het uitgebreidheidsniveau van de opdracht in. Toegestane waarden zijn
q[uiet]
, , ,n[ormal]
endiag[nostic]
d[etailed]
m[inimal]
. De standaardwaarde isminimal
. Zie LoggerVerbosity voor meer informatie.
args
Hiermee geeft u extra argumenten op die moeten worden doorgegeven aan de adapter. Gebruik een spatie om meerdere argumenten te scheiden.
De lijst met mogelijke argumenten is afhankelijk van het opgegeven gedrag:
- Wanneer u een project, oplossing of map opgeeft of als u dit argument weglaat, wordt de aanroep doorgestuurd naar
msbuild
. In dat geval vindt u de beschikbare argumenten in de dotnet msbuild-documentatie. - Wanneer u een .dll of een .exe opgeeft, wordt de oproep doorgestuurd naar
vstest
. In dat geval vindt u de beschikbare argumenten in de dotnet vstest-documentatie.
- Wanneer u een project, oplossing of map opgeeft of als u dit argument weglaat, wordt de aanroep doorgestuurd naar
RunSettings
Argumenten
Inline RunSettings
wordt doorgegeven als de laatste argumenten op de opdrachtregel na '-- ' (let op de spatie na --). Inline RunSettings
wordt opgegeven als [name]=[value]
paren. Er wordt een spatie gebruikt om meerdere [name]=[value]
paren te scheiden.
Voorbeeld: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True
Zie RunSettings-argumenten doorgeven via de opdrachtregel voor meer informatie.
Voer de tests uit in het project in de huidige map:
.NET CLIdotnet test
Voer de tests in het
test1
project uit:.NET CLIdotnet test ~/projects/test1/test1.csproj
Voer de tests uit met behulp van
test1.dll
assembly:.NET CLIdotnet test ~/projects/test1/bin/debug/test1.dll
Voer de tests uit in het project in de huidige map en genereer een testresultatenbestand in de trx-indeling:
.NET CLIdotnet test --logger trx
Voer de tests uit in het project in de huidige map en genereer een codedekkingsbestand (nadat u Coverlet-collectors-integratie hebt geïnstalleerd):
.NET CLIdotnet test --collect:"XPlat Code Coverage"
Voer de tests uit in het project in de huidige map en genereer een codedekkingsbestand (alleen Windows):
.NET CLIdotnet test --collect "Code Coverage"
Voer de tests uit in het project in de huidige map en meld u met gedetailleerde uitgebreidheid aan bij de console:
.NET CLIdotnet test --logger "console;verbosity=detailed"
Voer de tests uit in het project in de huidige map en meld u aan met de trx-logger om TestResults.trx te testen in de map TestResults :
.NET CLIdotnet test --logger "trx;logfilename=testResults.trx"
Omdat de naam van het logboekbestand is opgegeven, wordt dezelfde naam gebruikt voor elk doelframework in het geval van een project met meerdere doelen. De uitvoer voor elk doelframework overschrijft de uitvoer voor voorgaande doelframeworks. Het bestand wordt gemaakt in de map TestResults in de map testproject, omdat relatieve paden relatief zijn ten opzichte van die map. In het volgende voorbeeld ziet u hoe u voor elk doelframework een afzonderlijk bestand maakt.
Voer de tests uit in het project in de huidige map en meld u aan met de trx-logger naar bestanden in de map TestResults , met bestandsnamen die uniek zijn voor elk doelframework:
.NET CLIdotnet test --logger:"trx;LogFilePrefix=testResults"
Voer de tests uit in het project in de huidige map en meld u aan met de HTML-logboekregistratie om te testResults.html in de map TestResults:
.NET CLIdotnet test --logger "html;logfilename=testResults.html"
Voer de tests uit in het project in de huidige map en meld tests die werden uitgevoerd toen de testhost vastliep:
.NET CLIdotnet test --blame
Voer de tests in het
test1
project uit en geef het-bl
argument (binair logboek) op voormsbuild
:.NET CLIdotnet test ~/projects/test1/test1.csproj -bl
Voer de tests in het
test1
project uit en stel de eigenschap MSBuildDefineConstants
in opDEV
:.NET CLIdotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
Voer de tests in het
test1
project uit en stel de eigenschap MSBuildTestTfmsInParallel
in opfalse
:.NET CLIdotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
--filter <EXPRESSION>
<Expression>
heeft de indeling <property><operator><value>[|&<Expression>]
.
<property>
is een kenmerk van de Test Case
. Hier volgen de eigenschappen die worden ondersteund door populaire frameworks voor eenheidstests:
Testframework | Ondersteunde eigenschappen |
---|---|
MSTest |
|
xUnit |
|
Eenheid |
|
Hierin <operator>
wordt de relatie tussen de eigenschap en de waarde beschreven:
Operator | Functie |
---|---|
= |
Exacte overeenkomst |
!= |
Niet exacte overeenkomst |
~ |
Contains |
!~ |
Bevat geen |
<value>
is een tekenreeks. Alle zoekacties zijn hoofdlettergevoelig.
Een expressie zonder een <operator>
wordt automatisch beschouwd als een contains
on-eigenschap FullyQualifiedName
(bijvoorbeeld dotnet test --filter xyz
hetzelfde als dotnet test --filter FullyQualifiedName~xyz
).
Expressies kunnen worden samengevoegd met voorwaardelijke operators:
Operator | Functie |
---|---|
| |
OF |
& |
EN |
U kunt expressies tussen haakjes zetten wanneer u voorwaardelijke operatoren gebruikt (bijvoorbeeld (Name~TestMethod1) | (Name~TestMethod2)
).
.NET-feedback
.NET is een open source project. Selecteer een koppeling om feedback te geven: