dotnet-teszt VSTesttel

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

Név

dotnet test - .NET-tesztillesztő a VSTesttel végzett egységtesztek végrehajtásához.

Áttekintés

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

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.

Megjegyzé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ó: dotnet test with MTP.

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

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 az összes olyan parancs implicit módon fut, 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 buildeket az Azure DevOps Services vagy olyan buildrendszerekben, amelyeknek explicit módon kell szabályozni a visszaállítást.

További információ a NuGet-hírcsatornák kezeléséről: dotnet restore dokumentáció.

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.

Arguments

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

• -a|--arch <ARCHITECTURE>

  A célarchitektúra megadása. Ez a rövidített szintaxis a futtatókörnyezet-azonosító (RID)beállítására szolgál, ahol a megadott érték az alapértelmezett RID-vel van kombinálva. Egy win-x64 gépen például a --arch x86 megadásával a RID win-x86lesz. Ha ezt a lehetőséget használja, ne használja a -r|--runtime lehetőséget. 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 Kimeneti elrendezés. 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, NUnit és MSTest 2.2.4+ esetén 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.

• --disable-build-servers

  Kényszeríti a parancsot az állandó buildkiszolgálók figyelmen kívül hagyására. Ez a beállítás konzisztens módot biztosít a buildek gyorsítótárazásának letiltására, ami az alapoktól kényszeríti a buildeket. A gyorsítótárakra nem támaszkodó buildek akkor hasznosak, ha a gyorsítótárak valamilyen okból sérültek vagy helytelenek. A .NET 7 SDK óta érhető el.

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

• -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 --no-restore jelzőt 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 a --output beállítást adja meg, amikor ezt a 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öbbcélú projektekkel, valamint a közvetlen és tranzitív függőségek különböző verzióival rendelkező projektekhez. További információ: 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 a rövidített szintaxis a futtatókörnyezet-azonosító (RID)beállítására szolgál, ahol a megadott érték az alapértelmezett RID-vel van kombinálva. Egy win-x64 gépen például a --os linux megadásával a RID linux-x64lesz. Ha ezt a lehetőséget használja, ne használja a -r|--runtime lehetőséget. A .NET 6 óta érhető el.

• --results-directory <RESULTS_DIR>

  A könyvtár, ahova a teszteredményeket el fogják helyezni. Ha a megadott könyvtár nem létezik, az létrehozásra kerül. 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.

• --tl:[auto|on|off]

  Megadja, hogy a terminálnaplózót használni kell-e a buildkimenethez. Az alapértelmezett érték a auto, amely először ellenőrzi a környezetet a terminálnaplózás engedélyezése előtt. A környezet ellenőrzi, hogy a terminál képes-e modern kimeneti funkciókat használni, és nem használ átirányított szabványos kimenetet az új naplózó engedélyezése előtt. on kihagyja a környezetellenőrzést, és engedélyezi a terminálnaplózást. off kihagyja a környezetellenőrzést, és az alapértelmezett konzolnaplózót használja.

  A Terminálnaplózó megjeleníti a visszaállítási fázist, majd a buildelési fázist. Az egyes fázisok során az éppen épülő projektek a terminál alján jelennek meg. Az épület összes projektje az MSBuild-célt és a célra fordított időt is kimeneteli. Ebben az információban további információt talál a buildről. Amikor egy projekt befejeződött, egyetlen "befejezett build" szakasz lesz megírva, amely rögzíti a következőt:

  • Az épített projekt neve.
  • A cél-keretrendszer (ha több-célzott).
  • A build állapota.
  • A build elsődleges kimenete (amely hivatkozásra van hivatkozva).
  • A projekthez létrehozott diagnosztikák.

  Ez a beállítás a .NET 8-tól érhető el.

• -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 a minimal. További információért lásd 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 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 Microsoft Code Coverage:

  dotnet test --collect "Code Coverage"
  

• Futtassa a teszteket a projektben az aktuális könyvtárban, és hozzon létre egy kódlefedettségi fájlt Coverlet használatával (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 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 OsztályNév Priority TestCategory
xUnit	Teljesen minősített név Megjelenítendő név Kategória
NUnit	Teljesen minősített név Név Kategória Priority

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

Operator	Funkció
=	Pontos egyezés
!=	Nem pontos egyezés
~	Tartalmaz
!~	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 <operator>contains kifejezés nélküli FullyQualifiedName 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:

Operator	Funkció
|	OR
&	AND

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

• Keretrendszerek és célok
• .NET-futtatókörnyezet-azonosító (RID) katalógus
• Runsettings argumentumok átadása parancssoron keresztül
• dotnet-teszt
• dotnet-teszt MTP-