dotnet test s VSTestem

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

Název

dotnet test – .NET testovací ovladač použitý k provádění testů jednotek pomocí nástroje VSTest.

Přehled

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

Description

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.

Poznámka:

dotnet test byl původně navržen tak, aby podporoval pouze VSTestprojekty založené na testech. Nejnovější verze testovacích architektur přidávají podporu pro Microsoft. Testing.Platform (MTP). Tato alternativní testovací platforma je odlehčí a rychlejší než VSTest a podporuje dotnet test různé možnosti příkazového řádku. Další informace najdete v tématu dotnet test s MTP.

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 .NET 9 SDK se tyto testy spouští paralelně. 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>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>

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 situacích, kdy explicitní obnovení dává smysl, například sestavení integrace kontinuá 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.

Arguments

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

Výstraha

Zásadní změny v možnostech:

Počínaje .NET 7: přepněte -a na alias --arch místo --test-adapter-path
Počínaje .NET 7: přepněte -r na alias --runtime místo --results-directory

--test-adapter-path <ADAPTER_PATH>

Cesta k vlastním adaptérům, které se mají použít pro testovací běh.

Krátký formulář -a dostupný ve verzích .NET SDK starších než 7.
-a|--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 .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ů. Tato možnost a zadaná hodnota musí být explicitně kaskádové v libovolném dotnet příkazu, který závisí na výstupu jiného dotnet příkazu, například při použití dotnet build --no-restore a dotnet publish --no-build. K dispozici od .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 .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 verzi .NET použité, typu chyby a operačním systému.

U výjimek ve spravovaném kódu se výpis paměti automaticky shromažďuje na .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 .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 na 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 v 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é na .NET 5.0 nebo novější, můžete použití nástroje Procdump vynutit nastavením proměnné prostředí VSTEST_DUMP_FORCEPROCDUMP na 1.
--blame-crash-dump-type <DUMP_TYPE> (k dispozici od .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 .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 .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 .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 .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+ se časový limit 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 na Windows s netcoreapp2.1 a novějším v Linuxu s netcoreapp3.1 a novějšími a v macOS s net5.0 nebo novějším. 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, Zajistit analýzu pokrytí kódu a GitHub problém 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.
--disable-build-servers

Vynutí příkaz ignorovat všechny trvalé buildové servery. Tato možnost poskytuje konzistentní způsob, jak zakázat veškeré použití ukládání sestavení do mezipaměti, což vynutí sestavení úplně od začátku. Sestavení, které nespoléhá na mezipaměti, je užitečné, když jsou mezipaměti z nějakého důvodu poškozené nebo nesprávné. K dispozici od .NET 7 SDK.
-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í.
-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í. Také implicitně nastaví příznak --no-restore.
--nologo

Spusťte testy bez zobrazení banneru Microsoft TestPlatform. K dispozici od .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.
- .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 .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 .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 x86 .NET Core. Bitová verze dotnet.exe , která je na cestě, je to, co se použije ke spouštění testů. Další informace najdete v následujících zdrojích informací:
- 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ů.
--tl:[auto|on|off]

Určuje, jestli se má pro výstup sestavení použít terminálový protokolovací nástroj . Výchozí hodnota je auto, která nejprve ověří prostředí před povolením protokolování terminálu. Prostředí ověřuje, že terminál dokáže používat moderní výstupní funkce a nepoužívá přesměrovaný standardní výstup, než povolí nový protokolovací modul. on přeskočí kontrolu prostředí a povolí protokolování terminálu. off přeskočí kontrolu prostředí a použije výchozí protokolovací nástroj konzoly.

Terminal Logger ukazuje fázi obnovení následovanou fází sestavení. Během každé fáze se aktuálně stavební projekty zobrazují v dolní části terminálu. Každý projekt, který vytváří výstupy cíle NÁSTROJE MSBuild, který se právě sestavuje, i dobu strávenou na daném cíli. Další informace o sestavení najdete v těchto informacích. Po dokončení sestavení projektu se zapíše jeden oddíl "sestavení dokončeno", který zachycuje:
- Název sestaveného projektu.
- Cílová architektura (pokud je cílená na více cílů).
- Stav tohoto sestavení.
- Primární výstup tohoto sestavení (který je hypertextový odkaz).
- Všechna diagnostika vygenerovaná pro tento projekt.
Tato možnost je dostupná od .NET 8.
-v|--verbosity <LEVEL>

Nastaví úroveň podrobností příkazu. Povolené hodnoty jsou q[uiet], , m[inimal]n[ormal], d[etailed]a diag[nostic]. Výchozí hodnota je minimal. Další informace najdete v tématu 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 najdete v tématu Passing RunSettings argumenty prostřednictvím příkazového řádku.

Examples

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 pomocí Microsoft Pokrytí kódu:
```
dotnet test --collect "Code Coverage"
```
Spusťte testy v projektu v aktuálním adresáři a vygenerujte soubor pokrytí kódu pomocí Coverlet (po instalaci integrace kolektorů Coverlet u):
```
dotnet test --collect:"XPlat 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
```

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

Testovací architektura	Podporované vlastnosti
MSTest	FullyQualifiedName Název TřídaNázev Priority TestCategory
xUnit	FullyQualifiedName ZobrazovanéJméno Kategorie
NUnit	FullyQualifiedName Název Kategorie Priority

Popisuje <operator> vztah mezi vlastností a hodnotou:

Operator	Funkce
`=`	Přesná shoda
`!=`	Ne přesná shoda
`~`	Obsahuje
`!~`	Neobsahuje

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

Operator	Funkce
`\|`	OR
`&`	AND

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 (RID) .NET<>
Předávání argumentů runsettings prostřednictvím příkazového řádku
dotnet test
dotnet test s MTP

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-04-17