dotnet-teszt

Cikk
10/15/2024

Ez a cikk a következőre vonatkozik: ✔️ .NET Core 3.1 SDK és újabb verziók

Név

dotnet test - .NET-tesztillesztő az egységtesztek végrehajtásához.

Szinopszis

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

Leírás

A dotnet test parancs egy adott megoldás egységtesztjeinek végrehajtására szolgál. A dotnet test parancs létrehozza a megoldást, és futtat egy tesztgazdaalkalmazást a megoldás minden tesztprojektéhez a használatával VSTest. A tesztgazda teszteket hajt végre az adott projektben egy tesztelési keretrendszer használatával, például: MSTest, NUnit vagy xUnit, és az egyes tesztek sikerességét vagy sikertelenségét jelenti. Ha minden teszt sikeres, a tesztfuttató 0-t ad vissza kilépési kódként; ellenkező esetben, ha bármelyik teszt meghiúsul, az 1 értéket adja vissza.

Feljegyzés

dotnet test eredetileg csak VSTest-alapú tesztprojektek támogatására tervezték. A tesztelési keretrendszerek legújabb verziói támogatják a Microsoft.Testing.Platformot. Ez az alternatív tesztplatform egyszerűbb és gyorsabb, mint VSTest a különböző parancssori beállításokkal támogatott és támogatott dotnet test . További információ: Microsoft.Testing.Platform.

A több célzott projektek esetében a teszteket az egyes célzott keretrendszerekhez futtatjuk. A tesztgazda és az egységtesztelési keretrendszer NuGet-csomagként van csomagolva, és a projekt szokásos függőségeiként lesz visszaállítva. A .NET 9 SDK-tól kezdve ezek a tesztek alapértelmezés szerint párhuzamosan futnak. A párhuzamos végrehajtás letiltásához állítsa az TestTfmsInParallel MSBuild tulajdonságot a következőre false: . További információ: Tesztek párhuzamos futtatása és a jelen cikk későbbi, példa parancssora.

A tesztprojektek egy szokásos <PackageReference> elem használatával határozzák meg a tesztfuttatót, ahogyan az a következő mintaprojektfájlban látható:

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

Hol Microsoft.NET.Test.Sdk található a tesztgazda, xunit a tesztelési keretrendszer. Ez xunit.runner.visualstudio egy tesztadapter, amely lehetővé teszi, hogy az xUnit-keretrendszer működjön együtt a teszt gazdagéppel.

Implicit visszaállítás

Nem kell futtatnia dotnet restore , mert implicit módon fut minden olyan parancs, amely visszaállítást igényel, például dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishés dotnet pack. Az implicit visszaállítás letiltásához használja a --no-restore lehetőséget.

A dotnet restore parancs továbbra is hasznos bizonyos esetekben, amikor a explicit visszaállításnak van értelme, például folyamatos integrációs buildek az Azure DevOps Servicesben vagy olyan buildrendszerekben, amelyeknek explicit módon kell szabályozni a visszaállítást.

A NuGet-hírcsatornák kezelésével kapcsolatos információkért tekintse meg a dokumentációtdotnet restore.

Számítási feladatjegyzék letöltése

A parancs futtatásakor a rendszer elindítja a számítási feladatok hirdetési jegyzékeinek aszinkron háttérletöltését. Ha a letöltés a parancs befejeződésekor is fut, a letöltés leáll. További információ: Hirdetési jegyzékek.

Argumentumok

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- A tesztprojekt elérési útja.
- A megoldás elérési útja.
- Projekt vagy megoldás könyvtárának elérési útja.
- Egy tesztprojekt elérési útja .dll fájlhoz.
- Egy tesztprojekt elérési útja .exe fájlhoz.
Ha nincs megadva, az effektus ugyanaz, mint az DIRECTORY argumentum használata az aktuális könyvtár megadásához.

Beállítások

Figyelmeztetés

A beállítások kompatibilitástörő változásai:

A .NET 7-től kezdve: váltás -a aliasra --arch ahelyett, hogy --test-adapter-path
A .NET 7-től kezdve: váltás -r aliasra --runtime ahelyett, hogy --results-directory

Figyelmeztetés

Ha ezt használja Microsoft.Testing.Platform, tekintse meg a dotnet tesztintegrációt a támogatott lehetőségekhez. A hüvelykujjak szabálya szerint minden olyan lehetőség támogatott, amely nem kapcsolódik a teszteléshez, míg minden teszteléssel kapcsolatos lehetőség nem támogatott.

--test-adapter-path <ADAPTER_PATH>

További tesztadaptereket keresendő könyvtár elérési útja. A rendszer csak .dll utótaggal .TestAdapter.dll rendelkező fájlokat vizsgál. Ha nincs megadva, a rendszer megkeresi a teszt .dll könyvtárát.

A .NET SDK 7-nél korábbi verzióiban elérhető rövid űrlap -a .

--arch <ARCHITECTURE>

A célarchitektúra megadása. Ez egy rövidített szintaxis a futtatókörnyezet azonosítójának (RID) beállításához, ahol a megadott érték az alapértelmezett RID-vel van kombinálva. Egy gépen például win-x64 a RID beállítása a következőre win-x86van adva--arch x86: . Ha ezt a lehetőséget használja, ne használja a -r|--runtime beállítást. Elérhető a .NET 6 7. előzetes verziója óta.

--artifacts-path <ARTIFACTS_DIR>

A végrehajtott parancs összes buildkimeneti fájlja a megadott elérési út alatti almappákba kerül, projekt szerint elválasztva. További információ: Artifacts Output Layout. A .NET 8 SDK óta érhető el.

--blame

A teszteket hibás módban futtatja. Ez a lehetőség hasznos lehet olyan problémás tesztek elkülönítésében, amelyek a tesztgazda összeomlását okozzák. Összeomlás észlelésekor létrehoz egy szekvenciafájlt, amely TestResults/<Guid>/<Guid>_Sequence.xml rögzíti az összeomlás előtt futtatott tesztek sorrendjét.

Ez a beállítás nem hoz létre memóriaképet, és nem hasznos, ha a teszt le van függesztve.
--blame-crash (A .NET 5.0 SDK óta érhető el)

A teszteket hibás módban futtatja, és összegyűjt egy összeomlási memóriaképet, amikor a tesztgazda váratlanul kilép. Ez a beállítás a használt .NET-verziótól, a hiba típusától és az operációs rendszertől függ.

A felügyelt kód kivételei esetén a rendszer automatikusan gyűjti a memóriaképet a .NET 5.0-s és újabb verzióiban. Létrehoz egy memóriaképet a testhosthoz vagy bármely gyermekfolyamathoz, amely a .NET 5.0-n is futott és összeomlott. A natív kódban lévő összeomlások nem hoznak létre memóriaképet. Ez a beállítás Windows, macOS és Linux rendszeren is működik.

Az összeomlási memóriaképek natív kódban, illetve .NET Core 3.1 vagy korábbi verziók használatakor csak Windows rendszeren gyűjthetők össze a Procdump használatával. A procdump.exe és procdump64.exe tartalmazó címtárnak a PATH vagy PROCDUMP_PATH környezeti változóban kell lennie. Töltse le az eszközöket. Azt jelenti , --blamehogy .

Ha egy .NET 5.0-s vagy újabb rendszeren futó natív alkalmazásból szeretne összeomlási memóriaképet gyűjteni, a Procdump használata kényszeríthető a VSTEST_DUMP_FORCEPROCDUMP környezeti változó 1beállításával.
--blame-crash-dump-type <DUMP_TYPE> (A .NET 5.0 SDK óta érhető el)

Az összegyűjtendő összeomlási memóriakép típusa. A támogatott memóriaképtípusok full (alapértelmezett) és mini. Azt jelenti , --blame-crashhogy .
--blame-crash-collect-always (A .NET 5.0 SDK óta érhető el)

Összegyűjti a várt összeomlási memóriaképet, valamint a tesztgazda váratlan kilépését.
--blame-hang (A .NET 5.0 SDK óta érhető el)

Futtassa a teszteket hibás módban, és gyűjt egy lefagyási memóriaképet, ha egy teszt túllépi a megadott időtúllépést.
--blame-hang-dump-type <DUMP_TYPE> (A .NET 5.0 SDK óta érhető el)

Az összegyűjtendő összeomlási memóriakép típusa. Ennek kell lennie full, minivagy none. Ha none meg van adva, a teszt gazdagép időtúllépéskor leáll, de nem gyűjt memóriaképet. Azt jelenti , --blame-hanghogy .
--blame-hang-timeout <TIMESPAN> (A .NET 5.0 SDK óta érhető el)

Tesztenkénti időtúllépés, amely után lefagyási memóriakép aktiválódik, és a tesztgazdafolyamat és annak összes gyermekfolyamata ki lesz dobva és leáll. Az időtúllépési érték az alábbi formátumok egyikében van megadva:
- 1.5h, 1.5hour, 1.5hours
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000millisecond, 5400000milliseconds
Ha nincs használatban egység (például 5400000), akkor a rendszer azt feltételezi, hogy ezredmásodpercben van. Az adatvezérelt tesztekkel együtt használva az időtúllépés viselkedése a használt tesztadaptertől függ. XUnit esetén: NUnit. és MSTest 2.2.4+, az időtúllépés minden teszteset után megújul. A 2.2.4-es verzió előtti MSTest esetében az időtúllépés minden tesztesethez használható. Ez a beállítás windowsos netcoreapp2.1 és újabb rendszereken, Linuxon netcoreapp3.1 és újabb verziókban, valamint macOS-en net5.0 és újabb verziókban is támogatott. Azt jelenti, --blame és --blame-hang.

-c|--configuration <CONFIGURATION>

Meghatározza a buildkonfigurációt. A legtöbb projekt esetében az Debugalapértelmezett beállítás, de felülbírálhatja a projekt buildkonfigurációs beállításait.

--collect <DATA_COLLECTOR_NAME>

Engedélyezi az adatgyűjtőt a tesztfuttatáshoz. További információ: Tesztfuttatás figyelése és elemzése.

A kódlefedettség például a --collect "Code Coverage" beállítással gyűjthető össze. További információ: Kódlefedettség használata, Kódlefedettség-elemzés testreszabása és GitHub-probléma dotnet/docs#34479.

A kódlefedettség gyűjtéséhez a Coverletet is használhatja a --collect "XPlat Code Coverage" beállítással.
-d|--diag <LOG_FILE>

Engedélyezi a diagnosztikai módot a tesztplatform számára, és diagnosztikai üzeneteket ír a megadott fájlba és a mellette lévő fájlokba. Az üzenetek naplózásának folyamata határozza meg, hogy mely fájlok jönnek létre, például *.host_<date>.txt a tesztgazdanaplóhoz és *.datacollector_<date>.txt az adatgyűjtő naplóhoz.
-e|--environment <NAME="VALUE">

Beállítja egy környezeti változó értékét. Létrehozza a változót, ha nem létezik, felülbírálja, ha létezik. Ennek a beállításnak a használata arra kényszeríti a teszteket, hogy izolált folyamaton fussanak. A beállítás többször is megadható több változó megadásához.
-f|--framework <FRAMEWORK>

A cél-keretrendszer cél-keretrendszer-monikerje (TFM) a tesztek futtatásához. A cél keretrendszert a projektfájlban is meg kell adni.
--filter <EXPRESSION>

Az aktuális projekt tesztjeinek szűrése az adott kifejezés használatával. Csak a szűrőkifejezésnek megfelelő tesztek futnak. További információkért tekintse meg a Szűrés beállítás részletei című szakaszt . A szelektív egységtesztek szűrésével kapcsolatos további információkért és példákért lásd a szelektív egységtesztek futtatását ismertető témakört.

-?|-h|--help

A parancs használatának leírását nyomtatja ki.

--interactive

Lehetővé teszi, hogy a parancs leálljon, és várja meg a felhasználói bemenetet vagy műveletet. Például a hitelesítés befejezéséhez. A .NET Core 3.0 SDK óta érhető el.

-l|--logger <LOGGER>

Megadja a teszteredmények naplózóit, és opcionálisan átvált a naplózóra. Ezt a paramétert többször is megadhatja több naplózó engedélyezéséhez. További információkért lásd a jelentéskészítési teszt eredményeit, a naplózók kapcsolóit és a jelen cikk későbbi példáit .

A parancssori kapcsolók a naplózónak való átadásához:
- Használja a kapcsoló teljes nevét, ne a rövidített űrlapot (például verbosity helyett).v
- Kihagyja a bevezető kötőjeleket.
- Cserélje le az egyes kapcsolóktól elválasztó szóközt pontosvesszővel ;.
- Ha a kapcsoló értéke van, cserélje le a kettőspont-elválasztót a kapcsoló és annak értéke között az egyenlőségjelre =.
Például a -v:detailed --consoleLoggerParameters:ErrorsOnly következő lesz verbosity=detailed;consoleLoggerParameters=ErrorsOnly: .
--no-build

Nem hozza létre a tesztprojektet a futtatás előtt. Implicit módon beállítja a jelölőt --no-restore is.
--nologo

Teszteket futtathat a Microsoft TestPlatform szalagcím megjelenítése nélkül. A .NET Core 3.0 SDK óta érhető el.
--no-restore

Nem hajt végre implicit visszaállítást a parancs futtatásakor.
-o|--output <OUTPUT_DIRECTORY>

Könyvtár, amelyben a futtatandó bináris fájlok találhatók. Ha nincs megadva, az alapértelmezett elérési út a következő ./bin/<configuration>/<framework>/. Több cél-keretrendszerrel rendelkező projektek esetén (a tulajdonságon keresztül) ezt a TargetFrameworks beállítást is meg kell határoznia --framework . dotnet test mindig a kimeneti könyvtárból futtat teszteket. AppDomain.BaseDirectory A kimeneti könyvtárban használhat teszteszközöket.
- .NET 7.0.200 SDK és újabb verziók
  
  Ha ezt a --output parancsot egy megoldáson futtatja, a parancssori felület figyelmeztetést küld (7.0.200-ban hiba) a kimeneti útvonal nem egyértelmű szemantikája miatt. A --output beállítás nem engedélyezett, mert az összes beépített projekt kimenete a megadott könyvtárba lesz másolva, amely nem kompatibilis a több célzott projekttel, valamint a közvetlen és tranzitív függőségek különböző verzióival rendelkező projektekkel. További információ: A megoldásszintű --output beállítás már nem érvényes a buildel kapcsolatos parancsokra.

--os <OS>

A cél operációs rendszer (OS) megadása. Ez egy rövidített szintaxis a futtatókörnyezet azonosítójának (RID) beállításához, ahol a megadott érték az alapértelmezett RID-vel van kombinálva. Egy gépen például win-x64 a RID beállítása a következőre linux-x64van adva--os linux: . Ha ezt a lehetőséget használja, ne használja a -r|--runtime beállítást. A .NET 6 óta érhető el.

--results-directory <RESULTS_DIR>

A könyvtár, ahol a teszteredmények el lesznek helyezve. Ha a megadott könyvtár nem létezik, létrejön. Az alapértelmezett érték a projektfájlt tartalmazó könyvtárban van TestResults .

A .NET SDK 7-nél korábbi verzióiban elérhető rövid űrlap -r .
-r|--runtime <RUNTIME_IDENTIFIER>

A tesztelni kívánt futtatókörnyezet.

A .NET SDK 7-től kezdve elérhető rövid űrlap -r .
-s|--settings <SETTINGS_FILE>

A .runsettings tesztek futtatásához használandó fájl. Az TargetPlatform elemnek (x86|x64) nincs hatása.dotnet test Az x86-ot célzó tesztek futtatásához telepítse a .NET Core x86-os verzióját. A tesztek futtatásához az útvonalon található dotnet.exe bitképessége lesz használva. További információt a következő források tartalmaznak:
- Egységtesztek konfigurálása fájl .runsettings használatával.
- Tesztfuttatás konfigurálása
-t|--list-tests

A felderített tesztek listázása a tesztek futtatása helyett.

-v|--verbosity <LEVEL>

A parancs részletességi szintjét állítja be. Az engedélyezett értékek a következőkq[uiet]: , m[inimal], n[ormal]d[etailed]és diag[nostic]. Az alapértelmezett érték minimal. További információ: LoggerVerbosity.

args

Az adapternek továbbítandó további argumentumokat adja meg. Több argumentum elválasztásához használjon szóközt.

A lehetséges argumentumok listája a megadott viselkedéstől függ:
- Ha egy projektet, megoldást vagy könyvtárat ad meg, vagy ha kihagyja ezt az argumentumot, a rendszer átirányítja a hívást a következőre msbuild: . Ebben az esetben az elérhető argumentumok megtalálhatók a dotnet msbuild dokumentációjában.
- Ha .dll vagy .exe ad meg, a program a hívást a következőre vstesttovábbítja: . Ebben az esetben az elérhető argumentumok megtalálhatók a dotnet vstest dokumentációjában.
RunSettings Érvek

A beágyazott RunSettings szöveg a parancssor utolsó argumentumaként lesz átadva a következő után: "-- " (jegyezze fel a szóközt a következő után: --). A beágyazott RunSettings szöveg párként [name]=[value] van megadva. Több pár elválasztására [name]=[value] használunk szóközt.

Példa: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

További információ: Passing RunSettings argumentumok parancssoron keresztül.

Példák

Futtassa a teszteket a projektben az aktuális könyvtárban:
```
dotnet test
```

Futtassa a teszteket a test1 projektben:

dotnet test ~/projects/test1/test1.csproj

Futtassa a teszteket szerelvény használatával test1.dll :
```
dotnet test ~/projects/test1/bin/debug/test1.dll
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és hozzon létre egy teszteredmény-fájlt trx formátumban:
```
dotnet test --logger trx
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és hozzon létre egy kódlefedettségi fájlt (a Coverlet collectors integráció telepítése után):
```
dotnet test --collect:"XPlat Code Coverage"
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és hozzon létre egy kódlefedettségi fájlt (csak Windows esetén):
```
dotnet test --collect "Code Coverage"
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és jelentkezzen be részletes részletességgel a konzolon:
```
dotnet test --logger "console;verbosity=detailed"
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és jelentkezzen be a trx loggerrel a TestResults.trx teszteléséhez a TestResults mappában:
```
dotnet test --logger "trx;logfilename=testResults.trx"
```
Mivel a naplófájl neve meg van adva, a rendszer ugyanazt a nevet használja az egyes cél-keretrendszerekhez több célprojekt esetén. Az egyes cél-keretrendszerek kimenete felülírja az előző cél-keretrendszerek kimenetét. A fájl a tesztprojekt mappájának TestResults mappájában jön létre, mert a relatív elérési utak az adott mappához viszonyítva vannak. Az alábbi példa bemutatja, hogyan hozhat létre külön fájlt az egyes cél-keretrendszerekhez.
Futtassa a teszteket a projektben az aktuális könyvtárban, és jelentkezzen be a trx loggerrel a TestResults mappában lévő fájlokba, az egyes cél-keretrendszerekhez egyedi fájlnevekkel:
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és jelentkezzen be a html-naplózóval a TestResults mappában testResults.html:
```
dotnet test --logger "html;logfilename=testResults.html"
```
Futtassa a teszteket a projektben az aktuális könyvtárban, és jelentse a tesztgazda összeomlása során folyamatban lévő teszteket:
```
dotnet test --blame
```
Futtassa a teszteket a test1 projektben, és adja meg a -bl (bináris napló) argumentumot a következőhöz msbuild:
```
dotnet test ~/projects/test1/test1.csproj -bl
```
Futtassa a teszteket a test1 projektben, és állítsa az MSBuild tulajdonságot DefineConstants a következőre DEV:
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
Futtassa a teszteket a test1 projektben, és állítsa az MSBuild tulajdonságot TestTfmsInParallel a következőre false:
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--filter <EXPRESSION>

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

<property> a . Test Caseattribútuma. A népszerű egységtesztelési keretrendszerek az alábbiakat támogatják:

Tesztelési keretrendszer	Támogatott tulajdonságok
MSTest	Teljesen minősített név Név ClassName Prioritás TestCategory
xUnit	Teljesen minősített név Megjelenített név Kategória
NUnit	Teljesen minősített név Név Kategória Prioritás

A <operator> tulajdonság és az érték közötti kapcsolatot írja le:

Operátor	Függvény
`=`	Pontos egyezés
`!=`	Nem pontos egyezés
`~`	Contains
`!~`	Nem tartalmaz

<value> egy sztring. Minden keresés érzéketlen a kis- és nagybetűk között.

A rendszer automatikusan on tulajdonságnak tekint egy contains FullyQualifiedName kifejezés nélküli <operator> kifejezést (például ugyanaz, dotnet test --filter xyz mint dotnet test --filter FullyQualifiedName~xyz).

A kifejezések feltételes operátorokkal csatlakoztathatók:

Operátor	Függvény
`\|`	VAGY
`&`	ÉS

A kifejezéseket zárójelbe helyezheti feltételes operátorok használata esetén (például (Name~TestMethod1) | (Name~TestMethod2)).

A szelektív egységtesztek szűrésével kapcsolatos további információkért és példákért lásd a szelektív egységtesztek futtatását ismertető témakört.

Megosztás a következőn keresztül: