dotnet-test

  • Artikel

Dit artikel is van toepassing op: ✔️ .NET Core 3.1 SDK en latere versies

Naam

dotnet test - .NET-teststuurprogramma dat wordt gebruikt om eenheidstests uit te voeren.

Samenvatting

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

Beschrijving

De dotnet test opdracht wordt gebruikt om eenheidstests uit te voeren in een bepaalde oplossing. Met dotnet test de opdracht wordt de oplossing gebouwd en wordt voor elk testproject in de oplossing een testhosttoepassing uitgevoerd. 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.

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>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.9.0" />
    <PackageReference Include="xunit" Version="2.8.0" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.8.0" />
  </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.

Impliciete herstelbewerking

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.

Downloads van workloadmanifesten

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.

Argumenten

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

Opties

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

  • --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 op win-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 op 1.

  • --blame-crash-dump-type <DUMP_TYPE> (Beschikbaar sinds .NET 5.0 SDK)

    Het type crashdump dat moet worden verzameld. Ondersteunde dumptypen zijn full (standaard) en mini. 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, miniof none. Wanneer none 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 met netcoreapp3.1 en hoger en in macOS met net5.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 van v).
    • 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 =.

    Zou bijvoorbeeld -v:detailed --consoleLoggerParameters:ErrorsOnly worden verbosity=detailed;consoleLoggerParameters=ErrorsOnly.

  • --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 de TargetFrameworks 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 op linux-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. Het TargetPlatform element (x86|x64) heeft geen effect voor dotnet 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 zijnq[uiet], , , n[ormal]en diag[nostic]d[etailed]m[inimal]. De standaardwaarde is minimal. 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.

  • 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 Run Instellingen-argumenten doorgeven via de opdrachtregel voor meer informatie.

Voorbeelden

  • Voer de tests uit in het project in de huidige map:

    dotnet test

  • Voer de tests in het test1 project uit:

    dotnet test ~/projects/test1/test1.csproj

  • Voer de tests uit met behulp van test1.dll assembly:

    dotnet 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:

    dotnet 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):

    dotnet test --collect:"XPlat Code Coverage"

  • Voer de tests uit in het project in de huidige map en genereer een codedekkingsbestand (alleen Windows):

    dotnet 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:

    dotnet 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 :

    dotnet 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:

    dotnet 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:

    dotnet 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:

    dotnet test --blame

  • Voer de tests in het test1 project uit en geef het -bl argument (binair logboek) op voor msbuild:

    dotnet test ~/projects/test1/test1.csproj -bl

  • Voer de tests in het test1 project uit en stel de eigenschap MSBuild DefineConstants in op DEV:

    dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"

  • Voer de tests in het test1 project uit en stel de eigenschap MSBuild TestTfmsInParallel in op false:

    dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false

Details van filteroptie

--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
  • FullyQualifiedName
  • Naam
  • ClassName
  • Prioriteit
  • TestCategory
xUnit
  • FullyQualifiedName
  • DisplayName
  • Categorie
Nunit
  • FullyQualifiedName
  • Naam
  • Categorie
  • Prioriteit

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

Zie Selectief eenheidstests uitvoeren voor meer informatie en voorbeelden over het gebruik van selectief eenheidstests.

Zie ook