dotnet-teszt

  • Cikk

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 egyes tesztprojektjeihez. 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.

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.9.0" />
    <PackageReference Include="xunit" Version="2.7.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.8" />
  </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

  • --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ókat találhat az alábbi forrásokban:

  • -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ó: Futtatás továbbítása Gépház 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

Szűrési beállítás részletei

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

Lásd még