dotnet test

Tento článek se vztahuje na: ✔️ .NET Core 3.1 SDK a novější verze

Název

dotnet test – Ovladač testu .NET použitý k provádění testů jednotek.

Synopse

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

Popis

Příkaz dotnet test se používá k provádění testů jednotek v daném řešení. Příkaz dotnet test sestaví řešení a spustí testovací hostitelskou aplikaci pro každý testovací projekt v řešení pomocí VSTest. Hostitel testu provádí testy v daném projektu pomocí testovací architektury, například MSTest, NUnit nebo xUnit a hlásí úspěch nebo selhání každého testu. Pokud jsou všechny testy úspěšné, vrátí spouštěč testů hodnotu 0 jako ukončovací kód; jinak pokud některý test selže, vrátí hodnotu 1.

U projektů s více cíli se testy spouští pro každou cílovou architekturu. Testovací hostitel a architektura testování jednotek jsou zabalené jako balíčky NuGet a jsou obnoveny jako běžné závislosti pro projekt. Počínaje sadou .NET 9 SDK se tyto testy spouští paralelně ve výchozím nastavení. Chcete-li zakázat paralelní provádění, nastavte TestTfmsInParallel vlastnost MSBuild na falsehodnotu . Další informace naleznete v tématu Paralelní spouštění testů a ukázkový příkazový řádek dále v tomto článku.

Projekty testů určují spouštěč testů pomocí běžného <PackageReference> prvku, jak je vidět v následujícím ukázkovém souboru projektu:

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

Kde Microsoft.NET.Test.Sdk je testovací hostitel, xunit je testovací architektura. A xunit.runner.visualstudio je to testovací adaptér, který umožňuje rozhraní xUnit pracovat s testovacím hostitelem.

Implicitní obnovení

Nemusíte spouštětdotnet restore, protože se spouští implicitně všemi příkazy, které vyžadují obnovení, například dotnet new, , dotnet build, dotnet run, dotnet testdotnet publisha dotnet pack. Pokud chcete zakázat implicitní obnovení, použijte tuto --no-restore možnost.

Příkaz dotnet restore je stále užitečný v určitých scénářích, kdy explicitní obnovení dává smysl, například sestavení kontinuální integrace ve službě Azure DevOps Services nebo v systémech sestavení, které potřebují explicitně řídit, kdy dojde k obnovení.

Informace o správě informačních kanálů NuGet najdete v dotnet restore dokumentaci.

Stažení manifestu úloh

Při spuštění tohoto příkazu zahájí asynchronní stahování reklamních manifestů pro úlohy. Pokud stahování po dokončení tohoto příkazu stále běží, stahování se zastaví. Další informace naleznete v tématu Reklamní manifesty.

Argumenty

• PROJECT | SOLUTION | DIRECTORY | DLL | EXE

  • Cesta k testovacímu projektu
  • Cesta k řešení
  • Cesta k adresáři, který obsahuje projekt nebo řešení
  • Cesta k testovacímu projektu .dll souboru
  • Cesta k testovacímu projektu .exe souboru

  Pokud není zadaný, efekt je stejný jako použití argumentu DIRECTORY k určení aktuálního adresáře.

Možnosti

• --test-adapter-path <ADAPTER_PATH>

  Cesta k adresáři, který se má vyhledat pro další testovací adaptéry. Zkontrolují se pouze .dll soubory s příponou .TestAdapter.dll . Pokud není zadaný, prohledá se adresář testovacího .dll .

  Krátký formulář -a dostupný ve verzích sady .NET SDK starších než 7

• --arch <ARCHITECTURE>

  Určuje cílovou architekturu. Toto je zkratka pro nastavení identifikátoru runtime (RID), kde se zadaná hodnota zkombinuje s výchozím identifikátorem RID. Například na win-x64 počítači se zadáním --arch x86 identifikátoru RID nastaví na win-x86. Pokud použijete tuto možnost, tuto možnost nepoužívejte -r|--runtime . K dispozici od verze .NET 6 Preview 7.

• --artifacts-path <ARTIFACTS_DIR>

  Všechny výstupní soubory sestavení ze spuštěného příkazu budou v podsložkách pod zadanou cestou oddělenou projektem. Další informace naleznete v tématu Rozložení výstupu artefaktů. K dispozici od sady .NET 8 SDK.

• --blame

  Spustí testy v režimu blame. Tato možnost je užitečná při izolování problematických testů, které způsobují chybové ukončení hostitele testu. Při zjištění chybového ukončení vytvoří sekvenční soubor, který TestResults/<Guid>/<Guid>_Sequence.xml zachycuje pořadí testů, které byly spuštěny před chybovým ukončením.

  Tato možnost nevytvoří výpis paměti a není užitečná při zablokování testu.

• --blame-crash (K dispozici od sady .NET 5.0 SDK)

  Spustí testy v režimu blame a shromažďuje výpis stavu systému, když se hostitel testu neočekávaně ukončí. Tato možnost závisí na používané verzi rozhraní .NET, typu chyby a operačním systému.

  Pro výjimky ve spravovaném kódu se automaticky shromažďuje výpis paměti v .NET 5.0 a novějších verzích. Vygeneruje výpis paměti pro testhost nebo jakýkoli podřízený proces, který také běžel na rozhraní .NET 5.0 a došlo k chybě. Chybové ukončení v nativním kódu nevygeneruje výpis paměti. Tato možnost funguje ve Windows, macOS a Linuxu.

  Výpisy stavu systému v nativním kódu nebo při použití .NET Core 3.1 nebo starších verzí je možné shromažďovat pouze ve Windows pomocí nástroje Procdump. Adresář, který obsahuje procdump.exe a procdump64.exe , musí být v proměnné prostředí PATH nebo PROCDUMP_PATH. Stáhněte si nástroje. Implikuje --blame.

  Pokud chcete shromáždit výpis stavu systému z nativní aplikace spuštěné v .NET 5.0 nebo novější, může být použití nástroje Procdump vynuceno nastavením VSTEST_DUMP_FORCEPROCDUMP proměnné prostředí na 1hodnotu .

• --blame-crash-dump-type <DUMP_TYPE> (K dispozici od sady .NET 5.0 SDK)

  Typ výpisu stavu systému, který se má shromáždit. Podporované typy výpisu paměti jsou full (výchozí) a mini. Implikuje --blame-crash.

• --blame-crash-collect-always (K dispozici od sady .NET 5.0 SDK)

  Shromažďuje výpis stavu systému podle očekávání a také neočekávaný ukončení hostitele testu.

• --blame-hang (K dispozici od sady .NET 5.0 SDK)

  Spusťte testy v režimu blame a shromáždí výpis stavu, když test překročí daný časový limit.

• --blame-hang-dump-type <DUMP_TYPE> (K dispozici od sady .NET 5.0 SDK)

  Typ výpisu stavu systému, který se má shromáždit. Mělo by to být full, mininebo none. Po none zadání se testovací hostitel ukončí při vypršení časového limitu, ale neshromáždí se žádný výpis. Implikuje --blame-hang.

• --blame-hang-timeout <TIMESPAN> (K dispozici od sady .NET 5.0 SDK)

  Časový limit pro jednotlivé testy, po kterém se aktivuje výpis stavu systému, a proces hostitele testu a všechny jeho podřízené procesy se vypsají a ukončí. Hodnota časového limitu je zadána v jednom z následujících formátů:

  • 1.5h, 1.5hour, 1.5hours
  • 90m, 90min, 90minute, 90minutes
  • 5400s, 5400sec, 5400second, 5400seconds
  • 5400000ms, 540000000mil, 54000000 milisekund, 54000000 milisekund

  Pokud se nepoužívá žádná jednotka (například 54000000), předpokládá se, že hodnota je v milisekundách. Při použití společně s testy řízenými daty závisí chování časového limitu na použitém testovacím adaptéru. Pro xUnit, NUnit. a MSTest 2.2.4+, časový limit se obnoví po každém testovacím případu. Pro MSTest před verzí 2.2.4 se časový limit použije pro všechny testovací případy. Tato možnost je podporována ve Windows s a novějším netcoreapp2.1 , v Linuxu s a novějším netcoreapp3.1 a v macOS s nebo novějším net5.0 . Implikuje --blame a --blame-hang.

• -c|--configuration <CONFIGURATION>

  Definuje konfiguraci sestavení. Výchozí hodnota pro většinu projektů je Debug, ale můžete přepsat nastavení konfigurace sestavení v projektu.

• --collect <DATA_COLLECTOR_NAME>

  Povolí kolektor dat pro testovací běh. Další informace najdete v tématu Monitorování a analýza testovacího spuštění.

  Pomocí této možnosti můžete například shromažďovat pokrytí --collect "Code Coverage" kódu. Další informace najdete v tématu Použití pokrytí kódu, přizpůsobení analýzy pokrytí kódu a problému GitHubu dotnet/docs#34479.

  Ke shromažďování pokrytí kódu můžete také použít Coverlet pomocí této --collect "XPlat Code Coverage" možnosti.

• -d|--diag <LOG_FILE>

  Povolí diagnostický režim pro testovací platformu a zapisuje diagnostické zprávy do zadaného souboru a do souborů vedle ní. Proces, který protokoluje zprávy, určuje, které soubory se vytvoří, například *.host_<date>.txt pro protokol testovacího hostitele a *.datacollector_<date>.txt pro protokol kolektoru dat.

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

  Nastaví hodnotu proměnné prostředí. Vytvoří proměnnou, pokud neexistuje, přepíše, pokud existuje. Použití této možnosti vynutí spuštění testů v izolovaném procesu. Tuto možnost lze zadat vícekrát, aby bylo možné zadat více proměnných.

• -f|--framework <FRAMEWORK>

  Moniker cílové architektury (TFM) cílové architektury ke spuštění testů. V souboru projektu musí být zadána také cílová architektura.

• --filter <EXPRESSION>

  Filtruje testy v aktuálním projektu pomocí daného výrazu. Spustí se pouze testy, které odpovídají výrazu filtru. Další informace najdete v části Podrobnosti o možnostech filtru. Další informace a příklady použití filtrování selektivních testů jednotek naleznete v tématu Spouštění selektivních testů jednotek.

• -?|-h|--help

  Vytiskne popis použití příkazu.

• --interactive

  Umožňuje příkazu zastavit a čekat na uživatelský vstup nebo akci. Například k dokončení ověřování. K dispozici od sady .NET Core 3.0 SDK.

• -l|--logger <LOGGER>

  Určuje protokolovací nástroj pro výsledky testů a volitelně přepne protokolovací nástroj. Pokud chcete povolit více protokolovacích souborů, zadejte tento parametr vícekrát. Další informace najdete v tématu Vytváření sestav výsledků testů, přepínačů pro protokolovací nástroje a příklady dále v tomto článku.

  Aby bylo možné předávat přepínače příkazového řádku do protokolovacího nástroje:

  • Použijte úplný název přepínače, nikoli zkrácený tvar (například verbosity místo v).
  • Vynecháte všechny úvodní pomlčky.
  • Nahraďte mezeru oddělující každý přepínač středníkem ;.
  • Pokud má přepínač hodnotu, nahraďte oddělovač dvojtečky mezi tímto přepínačem a jeho hodnotou symbolem =rovná se .

  Například -v:detailed --consoleLoggerParameters:ErrorsOnly by se stal verbosity=detailed;consoleLoggerParameters=ErrorsOnly.

• --no-build

  Před spuštěním testovacího projektu se nevystaví. Příznak také implicitně nastaví --no-restore .

• --nologo

  Spouštění testů bez zobrazení banneru Microsoft TestPlatform K dispozici od sady .NET Core 3.0 SDK.

• --no-restore

  Při spuštění příkazu nespustí implicitní obnovení.

• -o|--output <OUTPUT_DIRECTORY>

  Adresář, ve kterém najdete binární soubory, které se mají spustit. Pokud není zadána, výchozí cesta je ./bin/<configuration>/<framework>/. U projektů s více cílovými architekturami (prostřednictvím TargetFrameworks vlastnosti) musíte také definovat --framework , kdy tuto možnost zadáte. dotnet test vždy spouští testy z výstupního adresáře. Můžete použít AppDomain.BaseDirectory ke využívání testovacích prostředků ve výstupním adresáři.

  • Sada .NET 7.0.200 SDK a novější

    Pokud při spuštění tohoto příkazu v řešení zadáte --output možnost, rozhraní příkazového řádku vygeneruje upozornění (chyba ve verzi 7.0.200) kvůli nejasné sémantice výstupní cesty. Možnost --output je zakázána, protože všechny výstupy všech sestavených projektů by se zkopírovaly do zadaného adresáře, který není kompatibilní s více cílenými projekty a projekty, které mají různé verze přímých a tranzitivních závislostí. Další informace najdete v tématu Možnost na úrovni --output řešení již neplatí pro příkazy související s sestavením.

• --os <OS>

  Určuje cílový operační systém (OS). Toto je zkratka pro nastavení identifikátoru runtime (RID), kde se zadaná hodnota zkombinuje s výchozím identifikátorem RID. Například na win-x64 počítači se zadáním --os linux identifikátoru RID nastaví na linux-x64. Pokud použijete tuto možnost, tuto možnost nepoužívejte -r|--runtime . K dispozici od .NET 6.

• --results-directory <RESULTS_DIR>

  Adresář, do kterého se umístí výsledky testu. Pokud zadaný adresář neexistuje, vytvoří se. Výchozí hodnota je TestResults v adresáři, který obsahuje soubor projektu.

  Krátký formulář -r dostupný ve verzích sady .NET SDK starších než 7

• -r|--runtime <RUNTIME_IDENTIFIER>

  Cílový modul runtime, pro který se má testovat.

  Krátký formulář -r dostupný od sady .NET SDK 7.

• -s|--settings <SETTINGS_FILE>

  Soubor .runsettings , který se má použít ke spuštění testů. Prvek TargetPlatform (x86|x64) nemá žádný vliv na dotnet test. Pokud chcete spustit testy, které cílí na x86, nainstalujte verzi .NET Core x86. Bitová verze dotnet.exe , která je na cestě, je to, co se použije ke spouštění testů. Další informace naleznete v následujících zdrojích:

  • Konfigurace testů jednotek pomocí .runsettings souboru
  • Konfigurace testovacího spuštění

• -t|--list-tests

  Vypíše zjištěné testy místo spuštění testů.

• -v|--verbosity <LEVEL>

  Nastaví úroveň podrobností příkazu. Povolené hodnoty jsou q[uiet], , n[ormal]m[inimal], d[etailed]a diag[nostic]. Výchozí hodnota je minimal. Další informace najdete na webu LoggerVerbosity.

• args

  Určuje další argumenty pro předání adaptéru. K oddělení více argumentů použijte mezeru.

  Seznam možných argumentů závisí na zadaném chování:

  • Když zadáte projekt, řešení nebo adresář nebo pokud tento argument vynecháte, volání se přesměruje na msbuild. V takovém případě se dostupné argumenty nacházejí v dokumentaci k nástroji msbuild dotnet.
  • Když zadáte .dll nebo .exe, hovor se přesměruje na vstest. V takovém případě najdete dostupné argumenty v dokumentaci k dotnet vstest.

• RunSettings argumenty

Vložený RunSettings řádek se předá jako poslední argumenty na příkazovém řádku za "--" (všimněte si mezery za --). RunSettings Vložené jsou zadány jako [name]=[value] páry. Mezera se používá k oddělení více [name]=[value] dvojic.

Příklad: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Další informace naleznete v tématu Předávání argumentů RunSettings prostřednictvím příkazového řádku.

Příklady

• Spusťte testy v projektu v aktuálním adresáři:

  dotnet test
  

• Spusťte testy v test1 projektu:

  dotnet test ~/projects/test1/test1.csproj
  

• Spusťte testy pomocí test1.dll sestavení:

  dotnet test ~/projects/test1/bin/debug/test1.dll
  

• Spusťte testy v projektu v aktuálním adresáři a vygenerujte soubor výsledků testů ve formátu trx:

  dotnet test --logger trx
  

• Spusťte testy v projektu v aktuálním adresáři a vygenerujte soubor pokrytí kódu (po instalaci integrace kolektorů Coverletu ):

  dotnet test --collect:"XPlat Code Coverage"
  

• Spusťte testy v projektu v aktuálním adresáři a vygenerujte soubor pokrytí kódu (jenom Windows):

  dotnet test --collect "Code Coverage"
  

• Spusťte testy v projektu v aktuálním adresáři a protokolujte s podrobnými podrobnostmi do konzoly:

  dotnet test --logger "console;verbosity=detailed"
  

• Spusťte testy v projektu v aktuálním adresáři a protokolujte pomocí protokolovacího nástroje trx do testResults.trx ve složce TestResults :

  dotnet test --logger "trx;logfilename=testResults.trx"
  

  Vzhledem k tomu, že je zadaný název souboru protokolu, použije se stejný název pro každou cílovou architekturu v případě projektu s více cíli. Výstup pro každou cílovou architekturu přepíše výstup pro předchozí cílové architektury. Soubor se vytvoří ve složce TestResults ve složce testovacího projektu, protože relativní cesty jsou relativní vzhledem k této složce. Následující příklad ukazuje, jak vytvořit samostatný soubor pro každou cílovou architekturu.

• Spusťte testy v projektu v aktuálním adresáři a protokolujte pomocí nástroje trx logger do souborů ve složce TestResults s názvy souborů, které jsou jedinečné pro každou cílovou architekturu:

  dotnet test --logger:"trx;LogFilePrefix=testResults"
  

• Spusťte testy v projektu v aktuálním adresáři a protokolujte protokolovacím nástrojem html, který testResults.html ve složce TestResults :

  dotnet test --logger "html;logfilename=testResults.html"
  

• Spusťte testy v projektu v aktuálním adresáři a nahlašte probíhající testy, když došlo k chybovému ukončení hostitele testu:

  dotnet test --blame
  

• Spusťte testy v test1 projektu a zadejte -bl argument (binární protokol) na msbuild:

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

• Spusťte testy v test1 projektu a nastavte vlastnost MSBuild DefineConstants na DEV:

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

• Spusťte testy v test1 projektu a nastavte vlastnost MSBuild TestTfmsInParallel na false:

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

Podrobnosti o možnostech filtrování

--filter <EXPRESSION>

<Expression> má formát <property><operator><value>[|&<Expression>].

<property> je atributem Test Case. Níže jsou uvedené vlastnosti podporované oblíbenými architekturami testování částí:

Popisuje <operator> vztah mezi vlastností a hodnotou:

<value> je řetězec. Všechna vyhledávání nerozlišují malá a velká písmena.

Výraz bez vlastnosti <operator> se automaticky považuje za contains FullyQualifiedName vlastnost (například dotnet test --filter xyz je stejný jako dotnet test --filter FullyQualifiedName~xyz).

Výrazy lze spojit s podmíněnými operátory:

Výrazy můžete uzavřít do závorek při použití podmíněných operátorů (například (Name~TestMethod1) | (Name~TestMethod2)).

Další informace a příklady použití filtrování selektivních testů jednotek naleznete v tématu Spouštění selektivních testů jednotek.

Viz také

• Architektury a cíle
• Katalog identifikátorů modulu runtime .NET (RID)
• Předávání argumentů runsettings prostřednictvím příkazového řádku