dotnet test
Tento článek se vztahuje na: ✔️ .NET Core 3.1 SDK a novější verze
dotnet test
– Ovladač testu .NET použitý k provádění testů jednotek.
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
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 VSTest
projekty založené na testech. Nejnovější verze testovacích architektur přidávají podporu pro Microsoft.Testing.Platform. Tato alternativní testovací platforma je odlehčí a rychlejší než VSTest
a podporuje dotnet test
různé možnosti příkazového řádku. Další informace naleznete v tématu Microsoft.Testing.Platform.
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 false
hodnotu . 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.
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 test
dotnet publish
a 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.
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.
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.
Upozornění
Zásadní změny v možnostech:
- Počínaje rozhraním .NET 7: Přepněte
-a
na alias--arch
místo--test-adapter-path
- Počínaje rozhraním .NET 7: Přepněte
-r
na alias--runtime
místo--results-directory
Upozornění
Při použití Microsoft.Testing.Platform
najdete informace o podporovaných možnostech v integraci testu dotnet. Obecně platí, že každá možnost nesouvisená s testováním se podporuje, i když každá možnost související s testováním není podporovaná tak, jak je.
--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í nawin-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í na1
hodnotu .--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í) amini
. 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
,mini
nebonone
. Ponone
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šímnetcoreapp3.1
a v macOS s nebo novějšímnet5.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ístov
). - 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 stalverbosity=detailed;consoleLoggerParameters=ErrorsOnly
.- Použijte úplný název přepínače, nikoli zkrácený tvar (například
--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ímTargetFrameworks
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í nalinux-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ů. PrvekTargetPlatform
(x86|x64) nemá žádný vliv nadotnet 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:-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]
adiag[nostic]
. Výchozí hodnota jeminimal
. 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.
- Když zadáte projekt, řešení nebo adresář nebo pokud tento argument vynecháte, volání se přesměruje na
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.
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) namsbuild
:dotnet test ~/projects/test1/test1.csproj -bl
Spusťte testy v
test1
projektu a nastavte vlastnost MSBuildDefineConstants
naDEV
:dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
Spusťte testy v
test1
projektu a nastavte vlastnost MSBuildTestTfmsInParallel
nafalse
: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 |
|
xUnit |
|
NUnit |
|
Popisuje <operator>
vztah mezi vlastností a hodnotou:
Operátor | Function |
---|---|
= |
Přesná shoda |
!= |
Ne přesná shoda |
~ |
Contains |
!~ |
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 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:
Operátor | Function |
---|---|
| |
NEBO |
& |
A |
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.
Zpětná vazba k produktu .NET
.NET je open source projekt. Vyberte odkaz pro poskytnutí zpětné vazby: