Microsoft. A Testing.Platform (MTP) parancssori felületének beállításaira vonatkozó referencia

Ez a cikk egy központi belépési pontot biztosít az MTP parancssori beállításaihoz.

Important

A platformbeállítások az MTP-ből érhetők el. A bővítménybeállítások csak akkor érhetők el, ha minden célzott tesztalkalmazás regisztrálja az őket biztosító bővítménycsomagot. Adja hozzá közvetlenül a csomagot, vagy használjon egy teszt SDK-konfigurációt vagy profilt, amely tartalmazza azt. Ha egy tesztalkalmazás nem regisztrálja a bővítményt, a futtatás az 5-ös kilépési kóddal meghiúsul, mert a beállítás ismeretlen.

Platformbeállítások

  • @

    Megadja a válaszfájl nevét. A válaszfájl nevének közvetlenül követnie kell a @ karaktert, nem lehet szóköz a @ karakter és a válaszfájl neve között.

    A válaszfájl beállításai úgy vannak értelmezve, mintha a parancssor ezen a helyén lennének. A fordított perjel karakter \ nem használható vonalak összefűzésére. A válaszfájl használata nagyon hosszú parancsok esetén segít, amelyek túlléphetik a terminálkorlátokat. A válaszfájlokat beágyazott parancssori argumentumokkal kombinálhatja. Például:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s
    

    ahol filter.rsp a következő tartalommal rendelkezhet:

    --filter "A very long filter"
    

    Vagy egyetlen rsp-fájl is használható az időtúllépés és a szűrés megadásához az alábbiak szerint:

    ./TestExecutable.exe @"arguments.rsp"
    
    --filter "A very long filter" --timeout 10s
    

    Megjegyzés:

    Használata esetén dotnet test az SDK parancssori elemzője egy token-per-line megközelítést használ, ahol a válaszfájl minden sorát egyetlen tokenként kezeli az SDK parancssori elemző. Ebben az esetben minden argumentumnak külön sorban kell lennie:

    --filter
    A very long filter
    --timeout
    10s
    
  • --config-file

    Egy testconfig.json fájlt ad meg.

  • --debug

    Indításkor szünetelteti a teszt végrehajtását, hogy hibakeresőt csatoljon a tesztelési folyamathoz. Egyenértékű a TESTINGPLATFORM_WAIT_ATTACH_DEBUGGER beállításával1. Böngészőplatformokon nem támogatott.

    Megjegyzés:

    Ez a lehetőség az MTP-ben érhető el az 1.9.0-s verziótól kezdve. Az előző --debug-wait-attach (az MTP 1.6.0-s verzióban bevezetett) lehetőséget váltja fel; a régi név el lett távolítva, és többé nem használható.

  • --diagnostic

    Engedélyezi a diagnosztikai naplózást. Az alapértelmezett naplószint a(z) Trace. Minden tesztforráshoz az MTP írja a következőt <asm>_<tfm>_<arch>_<timestamp>.diag: . Ha időbélyeg-ütközés történik, az MTP a meglévő fájl felülírása helyett folyamat- és számlálóutótagot ad hozzá.

  • --diagnostic-synchronous-write

    A beépített fájlnaplózót kényszeríti a naplók szinkronizálására. Olyan helyzetekben hasznos, amikor nem szeretné elveszíteni a naplóbejegyzéseket (ha a folyamat összeomlik). Ez lelassítja a teszt végrehajtását.

    Megjegyzés:

    Az MTP-ben a 2.0.0-s verziótól kezdve érhető el. Az előző --diagnostic-filelogger-synchronouswrite lehetőséget váltja fel, amely az MTP 2.0.0-s verzióban lett eltávolítva.

  • --diagnostic-output-directory

    A diagnosztikai naplózás kimeneti könyvtára, ha nincs megadva, a fájl az alapértelmezett TestResults könyvtárban jön létre.

  • --diagnostic-file-prefix

    A naplófájl nevének előtagja. Az alapértelmezett érték a <asm>_<tfm>_<arch>.

    Megjegyzés:

    Az MTP-ben a 2.0.0-s verziótól kezdve érhető el. Az előző --diagnostic-output-fileprefix lehetőséget váltja fel, amely az MTP 2.0.0-s verzióban lett eltávolítva.

  • --diagnostic-verbosity

    Meghatározza a bőbeszédűség szintjét, amikor a --diagnostic kapcsoló használatban van. Az elérhető értékek a következők: Trace, Debug, Information, Warning, Errorvagy Critical.

  • --enable-dynamic-extensions

    Lehetővé teszi a tesztalkalmazás mellett található *.testingplatformextensions.json jegyzékfájlok által deklarált bővítmények betöltését. A dinamikus bővítmények alapértelmezés szerint le vannak tiltva. A biztonsági követelményekről és a jegyzéksémáról a bővítmények dinamikus betöltése című témakörben olvashat.

    Megjegyzés:

    Ez a lehetőség az MTP-ben érhető el a 2.4.0-s verziótól kezdve.

  • --exit-on-process-exit

    Ha a függő folyamat kilép, lépjen ki a tesztelési folyamatból. A PID-t meg kell adni.

  • --filter-uid

    A futtatandó teszteket a tesztcsomópontjaik UID-jei alapján szűri. Egy vagy több felhasználói azonosítót fogad el.

    A keretrendszerek szerzőinek a felderítés és a végrehajtás során figyelembe kell venniük a(z) TestNodeUidListFilter elemet. A megvalósítással kapcsolatos útmutatásért tekintse meg a Kérésszűrők figyelembevétele.

    Megjegyzés:

    Ez a lehetőség az MTP-ben érhető el az 1.8.0-s verziótól kezdve. Az MTP 2.3.0-s verziójától kezdve a(z) --filter-uid és a(z) --treenode-filter nem kombinálható; mindkettő megadása esetén a parancssori ellenőrzés meghiúsul a(z) InvalidCommandLine kilépési kóddal.

  • --help

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

  • --ignore-exit-code

    Lehetővé teszi, hogy néhány nem nulla kilépési kód figyelmen kívül hagyható legyen, és ehelyett 0visszaadva. További információ: Adott kilépési kódok figyelmen kívül hagyása.

  • --info

    Speciális információkat jelenít meg a .NET tesztalkalmazásról, például:

    • A platform.
    • A környezet.
    • Minden regisztrált parancssori szolgáltató, például a name, version, descriptionés options.
    • Minden regisztrált eszköz, például a command, name, version, description, és minden parancssori szolgáltató.

    Ezzel a funkcióval megismerheti azokat a bővítményeket, amelyek ugyanazt a parancssori beállítást regisztrálnák, vagy a bővítmény (vagy a platform) több verziója között elérhető lehetőségek változásait.

  • --list-tests

    Megjeleníti az elérhető teszteket anélkül, hogy végrehajtanák őket. Igény szerint a kimeneti formátumot vezérlő argumentumot is használ: text (alapértelmezett, emberileg olvasható) vagy json.

    A strukturált metaadatokról és egy példáért lásd: Tesztek felderítése JSON-ként.

    Megjegyzés:

    A json kimeneti formátum az MTP-ben érhető el a 2.3.0-s verziótól kezdve.

  • --maximum-failed-tests

    A teszthibák pozitív maximális számát adja meg. Amikor a hibaszám eléri a maximumot, az MTP szabályos leállítást kér, és visszaadja a 13 kilépési kódot. A már folyamatban lévő tesztek befejeződhetnek, így a sikertelen tesztek végső száma meghaladhatja a maximális értéket. További információ: MTP kilépési kódok.

    A keretrendszer szerzőinek implementálniuk és regisztrálniuk kell a IGracefulStopTestExecutionCapability elemet, és a beállításszolgáltatót a AddMaximumFailedTestsService használatával kell regisztrálniuk. A képességdokumentáció megvalósítási és regisztrációs példákat tartalmaz. A tesztkészítőknek nem kell implementálniuk a funkciót, ha a keretrendszerük már támogatja ezt a lehetőséget.

    Megjegyzés:

    Ez a funkció az MTP-ben érhető el az 1.5-ös verziótól kezdve.

  • --minimum-expected-tests

    A futtatandó tesztek pozitív minimális számát adja meg. Ha a futtatás kevesebb tesztet hajt végre — akár egyet sem —, 9 kóddal lép ki. A kifejezetten megadott minimum felülírja a(z) --zero-tests-policy értéket.

    A dotnet test beállítással ez a beállítás a teljes futtatásra vonatkozik, ha a -- előtt adják meg, és az egyes tesztmodulokra, ha a -- után adják meg. További információ: Teljes futás és modulonkénti minimumok.

    Megjegyzés:

    --minimum-expected-tests 0 érvénytelen. A nullatesztek kilépési kódjának elnyomásához használja a(z) --ignore-exit-code 8 elemet.

  • --no-banner

    Letiltja az indítási szalagcímet, a szerzői jogi üzenetet és a telemetriai szalagcímet. Ugyanez a hatás a TESTINGPLATFORM_NOBANNERDOTNET_NOLOGO keresztül érhető el.

  • --results-directory

    Azt a könyvtárat adja meg, ahol az MTP teszteredményeket helyez el. Ha a könyvtár nem létezik, létrejön. Az alapértelmezett érték az TestResults MTP munkakönyvtára alatt van. Amikor közvetlenül elindít egy tesztalkalmazást, a munkakönyvtár alapértelmezés szerint a tesztalkalmazást tartalmazó könyvtárba lesz bekapcsolva.

    Az dotnet testalapértelmezett érték az SDK és az MTP verzióktól függ. A közös, meghíváshoz viszonyított gyökérkönyvtárra, a verziókövetelményekre és az artefaktumok elrendezésének felülírásaira vonatkozóan lásd a(z) Eredmények és artefaktumok című részt.

    Több tesztalkalmazás elkülönítéséhez adja meg az SDK --results-directory-layout per-module kapcsolóját a(z) -- előtt. Ez a beállítás az SDK-hoz tartozik, nem az MTP core-hoz, és nem érhető el, ha egy tesztalkalmazást közvetlenül indít el.

  • --server

    A tesztalkalmazást JSON-RPC kiszolgálói módban indítja el a szerkesztői, IDE- vagy eszközintegrációhoz. Hagyja ki az értéket, vagy használja jsonrpc. Támogatott csak forráskódú ügyfél esetén lásd: MTP-kiszolgáló mód.

    Important

    Az dotnettestcli érték és átviteli argumentumai a .NET SDK-integráción belül vannak. Ne adja át manuálisan.

  • --show-slowest-tests

    A terminál összegzésében a leglassabb tesztek kért számát jeleníti meg. Ha egy futtatás több tesztmodult tartalmaz, az MTP az egyes modulok leglassabb tesztjeit jelenti.

    Megjegyzés:

    Ez a lehetőség az MTP-ben érhető el a 2.4.0-s verziótól kezdve.

  • --timeout

    A globális teszt végrehajtásának időtúllépése. Egy argumentumot sztringként használ a <value>[h|m|s] formátumban, ahol a <value> egy lebegőpontos szám.

  • --treenode-filter

    Szűri a futtatandó teszteket egy faszűrő kifejezés használatával. A faszűrők gazdagabb egyezést kínálnak, mint --filter a speciális forgatókönyvek esetében.

    Megjegyzés:

    Az MTP 2.3.0-s verziójától kezdve a(z) --treenode-filter és a(z) --filter-uid nem kombinálható; mindkettő megadása esetén a parancssori ellenőrzés meghiúsul a(z) InvalidCommandLine kilépési kóddal.

  • --zero-tests-policy

    Azt szabályozza, hogy egy olyan futtatás, amely nem hajt végre teszteket, mert minden teszt kimaradt, hibaként lesz-e kezelve. Az érvényes értékek az (alapértelmezett) és a allow-skippedstrict. A(z) allow-skipped használatával egy csupa kihagyásból álló futtatás sikeresnek minősül. A(z) strict használatakor 8 kilépési kóddal meghiúsul. Egy explicit --minimum-expected-tests érték felülírja ezt a szabályzatot, és kilépési kódot 9 használ, ha a minimális érték nem teljesül.

    Megjegyzés:

    Ez a lehetőség a 2.3.0-s verziótól kezdve elérhető az MTP-ben. A dotnet test használatával adja meg az opciót a -- után, hogy az minden tesztmodulhoz továbbítódjon. Ha nem állít be globális minimumot, a .NET 11 SDK külön határozza meg a teljes körű nullateszt-ítéletet. További információ: Teljes futás és modulonkénti minimumok.

Tesztek felderítése JSON-ként

Az MTP 2.3.0-tól kezdve használja a(z) --list-tests json elemet a tesztek géppel olvasható JSON-dokumentumként való felderítéséhez az emberi olvasásra alkalmas lista elemzése helyett:

dotnet Contoso.MyTests.dll --list-tests json --no-banner

Futtassa a lefordított tesztalkalmazást a buildkimenetet is megíró parancs helyett. Kezelje a standard kimenetet a standard hibakimenettől elkülönítve, és a dokumentum feldolgozása előtt ellenőrizze a folyamat kilépési kódját. Az alkalmazás- és bővítményindítási üzeneteket tartsa távol a standard kimenetről gépi olvasási módban.

Ne kombinálja együtt a felderítést olyan csak végrehajtási beállításokkal, mint a(z) --report-trx. Ha a testconfig.json engedélyezi ezeket a beállításokat, használja a --config-file elemet egy külön felderítési konfigurációval, amely kihagyja azokat.

A dokumentum egy schemaVersion és egy tests tömböt tartalmaz. Minden teszt tartalmaz uid-t és displayName-et. Az opcionális mezők közé tartozik type, location, traits és properties, amikor a tesztkeret a megfelelő metaadatokat adja meg. Egy tulajdonsággal rendelkező Environment teszt például a következőt eredményezheti:

{
  "schemaVersion": 1,
  "tests": [
    {
      "uid": "<test-uid>",
      "displayName": "ConnectToService",
      "traits": [
        { "key": "Environment", "value": "Staging" }
      ]
    }
  ]
}

Mind a properties, mind a traits kulcs-érték bejegyzések tömbjeit használja, nem pedig JSON-objektumokat. Ne feltételezze, hogy a kulcsok egyediek. A tulajdonságok a nyilvános TestMetadataProperty értékeket képviselik, beleértve az MSTest-kategóriákat és az egyéni TestProperty értékeket. A properties tömb a platform vagy a kompatibilitási réteg által megadott szerializálható sztringtulajdonságokat tartalmazza. Nem exportál minden memóriabeli tulajdonságot, és belső SerializableKeyValuePairStringProperty típusa nem API a külső keretrendszerek vagy bővítmények számára.

A felderített UID-k használatával --filter-uid futtathat kijelölt teszteket. Felderítéssel, végrehajtással, megszakítással és élő frissítésekkel rendelkező típusos .NET-ügyfélhez használja az MTP-kiszolgálómódot.

Bővítménybeállítások forgatókönyv szerint

Az alábbi táblázat segítségével megtalálhatja az egyes bővítmények csomagját és beállításait. A teszt SDK-profilok közvetlen csomaghivatkozás helyett csomagokat is megadhatnak.

Scenario Szükséges összetevő Funkciódokumentáció
Kódlefedettség gyűjtése Microsoft.Testing.Extensions.CodeCoverage vagy coverlet.MTP Kódlefedettség
Összeomlási vagy lefagyásos memóriaképek gyűjtése Microsoft.Testing.Extensions.CrashDump vagy Microsoft.Testing.Extensions.HangDump Összeomlási és lefagyási memóriaképek
Tesztjelentések létrehozása A kijelölt formátum bővítménycsomagja, például Microsoft.Testing.Extensions.TrxReport Tesztjelentések
Terminálkimenet testreszabása MTP core (nincs további csomag) Terminálkimenet
Sikertelen tesztek újrapróbálkoztatása Microsoft.Testing.Extensions.Retry Újrapróbálkozás

Lehetőségek felfedezése a tesztalkalmazásban

Futtassa a tesztfuttatható fájlt a(z) --help kapcsolóval, vagy futtassa a(z) dotnet test --help elemet MTP módban az aktuális bővítménykészlethez elérhető beállítások megjelenítéséhez.

Az MTP 2.4-től kezdődően egy ismeretlen beállításhiba egy egyedileg egyező beállításnevet javasol, ha elérhető. Ha a beállítás egy ismert Microsoft által biztosított bővítményhez tartozik, amelyet a tesztalkalmazás nem regisztrált, a hiba a lehetőséget biztosító NuGet-csomagot is azonosítja.

A regisztrált szolgáltatók és opciók fejlett diagnosztikájához futtassa a következőt: --info.

Regisztrált eszköz futtatása

Egyes bővítmények olyan parancsokat regisztrálnak, amelyek a tesztek végrehajtása helyett artefaktumokat dolgoznak fel. Adja meg a parancs nevét a tesztalkalmazás első pozícióargumentumaként. Például a TRX-bővítmény merge-trx és ms-trxcompare.

Futtassa az alkalmazást a(z) --info használatával a regisztrált eszközök és azok parancssori beállításainak listázásához. Ezek a parancsok a tesztalkalmazáshoz tartoznak; ezek nem dotnet tool parancsok.

Lásd még