Migrálás VSTestről Microsoft.Testing.Platform (MTP)

Ebből a cikkből megtudhatja, hogyan migrálhat VSTestről MTP-re.

Ez a cikk a migrálás lépéseire és az argumentumok leképezésére összpontosít.

Ha továbbra is platformot kell választania, kezdje a tesztplatformok áttekintésével.

Ha dotnet test módok részletes viselkedésére kíváncsi, olvassa el a Tesztelés a következővel dotnet test-t:

Ha a platform- és bővítmény parancssori beállításainak egyetlen listájára van szüksége, tekintse meg az MTP parancssori felületének beállításaira vonatkozó referenciát.

Jótanács

A teljes adattárra kiterjedő migráció MI-alapú kódolási asszisztenssel történő automatizálásához telepítse a dotnet-test és bővítményeket a dotnet-test-migration szolgáltatásból. Kérje meg az test-migration ügynököt , hogy észlelje és migrálja a tesztbeállítást, vagy hívja meg az migrate-vstest-to-mtp adott migráláshoz szükséges képességet . Egyesítés előtt tekintse át a létrehozott módosításokat.

Bejelentkezés az MTP használatára

A migrálás első lépése az MTP használatának letiltása.

Az összes tesztelési keretrendszerhez adjon hozzá <OutputType>Exe</OutputType> a megoldás összes tesztprojektjéhez. Ezt követően kövesse a keretrendszerre vonatkozó útmutatást.

MSTest

Az MTP-t az MSTest támogatja a 3.2.0-val kezdődően. Javasoljuk azonban, hogy frissítsen a legújabb elérhető MSTest-verzióra.

A beleegyezéshez adja hozzá <EnableMSTestRunner>true</EnableMSTestRunner> a PropertyGroup elem alá a Directory.Build.props fájlban.

Megjegyzés:

Az MSTest.Sdk használatakor alapértelmezés szerint az MTP van használatban, hacsak nincs <UseVSTest>true</UseVSTest> megadva.

NUnit

Az MTP-t az NUnit3TestAdapter támogatja az 5.0.0-s verziótól kezdve.

A beleegyezéshez adja hozzá <EnableNUnitRunner>true</EnableNUnitRunner> a PropertyGroup elem alá a Directory.Build.props fájlban.

xUnit.net

Az MTP xunit.v3-tól kezdve támogatott.

A beleegyezéshez adja hozzá <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> a PropertyGroup elem alá a Directory.Build.props fájlban.

dotnet test

A .NET 9 SDK és korábbi verziókra való bejelentkezés

A .NET 9 SDK-ban és a korábbi verziókban nincs natív támogatás dotnet test MTP-hez. A támogatás a VSTest-infrastruktúrára épül. Ehhez adja hozzá <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> a PropertyGroup alá a Directory.Build.props fájlban.

Fontos

Ha MTP-támogatást futtat ebben a módban, akkor hozzá kell adnia -- az ahhoz, hogy elválaszthassa az dotnet test argumentumokat az új platformargumentumoktól. Például: dotnet test --no-build -- --list-tests.

A .NET 10 SDK és újabb verziókra való bejelentkezés

A .NET 10 SDK-tól kezdve natív támogatott az MTP. A használatához meg kell adnia a tesztfuttatót Microsoft.Testing.Platform a global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Fontos

Ebben a módban az extra -- már nem szükséges. A tesztalkalmazás argumentumainak egyértelmű továbbításához tartsa meg.

Frissítse a dotnet test hívásokat

A parancssori dotnet test lehetőségek két kategóriába sorolhatók: a buildel kapcsolatos argumentumokra és a teszteléssel kapcsolatosakra.

A buildel kapcsolatos argumentumok a tesztplatform szempontjából irrelevánsak, ezért nem kell frissíteni az új platformot. A buildel kapcsolatos paraméterek a következők:

• -a|--arch <ARCHITECTURE>
• --artifacts-path <ARTIFACTS_DIR>
• -c|--configuration <CONFIGURATION>
• -f|--framework <FRAMEWORK>
• -e|--environment <NAME="VALUE">
• --interactive
• --no-build
• --nologo
• --no-restore
• -o|--output <OUTPUT_DIRECTORY>
• --os <OS>
• -r|--runtime <RUNTIME_IDENTIFIER>
• -v|--verbosity <LEVEL>

Bár a --arch továbbra is a buildfolyamathoz kapcsolódó beállítás marad, felülírja azt az architektúrát, amelyet a VSTest a RunConfiguration.TargetPlatform használatával választ ki. Adja át a(z) --arch értéket magának a dotnet test-nek, bármilyen -- elválasztó előtt.

Migrálja például ezt a VSTest-projektparancsot:

dotnet test MyTests.csproj -c Debug -- RunConfiguration.TargetPlatform=x86 /Parallel

A .NET 10 SDK-s és újabb verziókhoz használja ezt az MTP-parancsot:

dotnet test --project MyTests.csproj -c Debug --arch x86

A(z) x64 elemet cserélje le erre: x86, az x64 célzásához. Az MTP alapértelmezés szerint párhuzamosan futtatja a tesztmodulokat, ezért /Parallel nincs szükség cserére. A modulszintű párhuzamosság korlátozásához használja --max-parallel-test-modules <NUMBER>a .

Fontos

Nem kombinálható --solution az --arch, --osvagy --runtime. Ezek a beállítások globális MSBuild tulajdonságként vannak beállítva RuntimeIdentifier , és a megoldás buildjei nem támogatják a globális RuntimeIdentifier. A megoldások architektúrák közötti teszteléséhez minden tesztprojektet külön hívjon meg, vagy állítsa be RuntimeIdentifier az egyes tesztprojektekben.

Cserélje le például ezt a négy megoldásszintű VSTest-parancsot:

dotnet test MySolution.sln -c Debug -- RunConfiguration.TargetPlatform=x86 /Parallel
dotnet test MySolution.sln -c Release -- RunConfiguration.TargetPlatform=x86 /Parallel
dotnet test MySolution.sln -c Debug -- RunConfiguration.TargetPlatform=x64 /Parallel
dotnet test MySolution.sln -c Release -- RunConfiguration.TargetPlatform=x64 /Parallel

A .NET 10 SDK-s és újabb verziókhoz használjon projektszintű mátrixot:

$testProjects = @("tests/A.Tests/A.Tests.csproj", "tests/B.Tests/B.Tests.csproj")
$testRunFailed = $false
foreach ($configuration in "Debug", "Release") {
    foreach ($architecture in "x86", "x64") {
        foreach ($testProject in $testProjects) {
            dotnet test --project $testProject -c $configuration --arch $architecture
            if ($LASTEXITCODE -ne 0) {
                $testRunFailed = $true
            }
        }
    }
}
if ($testRunFailed) {
    throw "One or more test runs failed."
}

A teszthez kapcsolódó argumentumok VSTest-specifikusak, ezért az új platformnak megfelelően kell átalakítani. Az alábbi táblázat a VSTest argumentumok és az új platform közötti megfeleltetést mutatja be:

VSTest argumentum	Új platformargumentum
--test-adapter-path <ADAPTER_PATH>	Nem releváns az MTP-hez
--blame	Nem releváns az MTP-hez
--blame-crash	--crashdump ( összeomlási memóriakép bővítményt igényel)
--blame-crash-dump-type <DUMP_TYPE>	--crashdump-type ( összeomlási memóriakép bővítményt igényel)
--blame-crash-collect-always	Nem támogatott
--blame-hang	--hangdump ( rendszer dump bővítményt igényel)
--blame-hang-dump-type <DUMP_TYPE>	--hangdump-type ( rendszer dump bővítményt igényel)
--blame-hang-timeout <TIMESPAN>	--hangdump-timeout ( rendszer dump bővítményt igényel)
--collect <DATA_COLLECTOR_NAME>	Az adatgyűjtőtől függ
-d\|--diag <LOG_FILE>	--diagnostic
--filter <EXPRESSION>	A kiválasztott tesztelési keretrendszertől függ
-l\|--logger <LOGGER>	A naplózótól függ
--results-directory <RESULTS_DIR>	--results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE>	A kiválasztott tesztelési keretrendszertől függ
-t\|--list-tests	--list-tests
-- RunConfiguration.TargetPlatform=<ARCHITECTURE>	--arch <ARCHITECTURE> egy projekt meghívásához
/Parallel	Nincs szükség opcióra. Az MTP alapértelmezés szerint párhuzamosan futtat tesztmodulokat.
-- <RunSettings arguments>	--test-parameter (előállítva a VSTestBridge által)

--collect

--collect egy általános bővíthetőségi pont a VSTestben minden adatgyűjtő esetében. Az MTP bővíthetőségi modellje eltérő, és nincs olyan központosított argumentum, amelyet minden adatgyűjtő használ. Az MTP-vel minden adatgyűjtő saját parancssori lehetőséget adhat hozzá. A Microsoft CodeCoverage VSTesten keresztüli futtatása például a következőhöz hasonló lehet:

dotnet test --collect "Code Coverage;Format=cobertura"

Az MTP-vel ez a következő lesz:

dotnet test --coverage --coverage-output-format cobertura

Fontos

A használathoz --coverageminden célzott tesztalkalmazásnak közvetlenül vagy egy azt tartalmazó teszt SDK-konfiguráción vagy profilon keresztül kell hivatkoznia a Microsoft.Testing.Extensions.CodeCoverage NuGet-csomagra.

Fontos

Ahogy korábban már elmagyaráztuk, az MTP VSTest-alapú dotnet test használata esetén további -- elemek szükségesek, mielőtt a platformnak átadni kívánt argumentumok továbbadhatók. Tehát ez lesz dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter A VSTest-alapú szűrő.

Az MSTest és az NUnit ugyanazt a szűrőformátumot támogatja akkor is, ha MTP-vel fut.

xUnit.net nem támogatja ugyanazt a szűrőformátumot az MTP-vel való futtatáskor. A VSTest-alapú szűrőről át kell telepítenie az xunit.v3 új szűrőtámogatására, amely a következő parancssori beállítások használatával érhető el.

xUnit.net konkrét beállítások:

• --filter-class
• --filter-not-class
• --filter-method
• --filter-not-method
• --filter-namespace
• --filter-not-namespace
• --filter-trait
• --filter-not-trait
• --filter-query

További információkért tekintse meg a Microsoft.Testing.Platform dokumentációját az xUnit.net számára és a lekérdezésszűrő nyelvének dokumentációját az xUnit.net számára.

Jótanács

Ha a megoldás különböző szűrőszintaxisokat (például MSTestet és xUnit.net) használó tesztelési keretrendszereket kever, feltételesen átirányíthatja a keretrendszerspecifikus argumentumokat az TestingPlatformCommandLineArguments MSBuild tulajdonság használatával. További részletekért lásd a vegyes tesztelési keretrendszereket vagy bővítményeket tartalmazó megoldásokat.

--logger

Amit a VSTestben általában "loggernek" neveztek, az MTP-ben "riporternek" is nevezik. Az MTP-ben a naplózás kifejezetten csak diagnosztikai célokra szolgál.

--collect --logger Ehhez hasonlóan a VSTest egy általános bővíthetőségi pontja minden naplózónak (vagy az MTP kontextusában bármely riporternek). Minden MTP-riporter saját parancssori lehetőséget adhat hozzá, és így nincs olyan központi parancssori lehetőség, mint a VSTest --logger.

Az egyik leggyakrabban használt VSTest-naplózó a TRX-naplózó. Ezt a naplózót általában a következőképpen hívjuk:

dotnet test --logger trx

Az MTP-vel a parancs a következő lesz:

dotnet test --report-trx

Fontos

A használathoz --report-trxminden célzott tesztalkalmazásnak közvetlenül vagy egy azt tartalmazó teszt SDK-konfiguráción vagy profilon keresztül kell hivatkoznia a Microsoft.Testing.Extensions.TrxReport NuGet-csomagra.

Fontos

Ahogy korábban már elmagyaráztuk, az MTP VSTest-alapú dotnet test használata esetén további -- elemek szükségesek, mielőtt a platformnak átadni kívánt argumentumok továbbadhatók. Tehát ez lesz dotnet test -- --report-trx.

GitHub Actions riporter beállításai csomagspecifikusak, és nem cserélhetők fel:

Riporteri csomag	MTP-beállítás
Microsoft. Testing.Extensions.GitHubActionsReport	--report-gh
GitHubActionsTestLogger	--report-github

A tesztalkalmazás csak akkor ismer fel egy lehetőséget, ha az azt tartalmazó csomag telepítve van és regisztrálva van. Ha például áttelepíti a(z) --logger GitHubActions-t, és megtartja a(z) GitHubActionsTestLogger csomagot, cserélje le a VSTest parancsot:

dotnet test --logger GitHubActions

A .NET 10 SDK-val és az újabb verziókkal használja a következőt:

dotnet test --report-github

A .NET 9 SDK és korábbi verziók esetén használja dotnet test -- --report-github helyette.

--settings

A VSTest egy --settings RunSettings-fájl megadására szolgál a tesztfuttatáshoz. A RunSettings-t az alapvető MTP nem támogatja, ezért egy modernebb testconfig.json konfigurációs fájl váltotta fel. Az MSTest és az NUnit azonban továbbra is támogatja a régi RunSettingst az MTP futtatásakor, és --settings továbbra is támogatott.

vstest.console.exe

Ha közvetlenül használja vstest.console.exe , javasoljuk, hogy cserélje le a dotnet test parancsra.

Tesztböngésző

Ha Visual Studio vagy Visual Studio Code Test Explorert használ, előfordulhat, hogy engedélyeznie kell az MTP támogatását.

Visual Studio

Visual Studio Test Explorer a 17.14-es verziótól kezdve támogatja az MTP-t. Ha egy korábbi verziót használ, előfordulhat, hogy frissítenie kell a Visual Studiót a legújabb verzióra.

Visual Studio Code

A Visual Studio Code a C# DevKit segítségével támogatja az MTP-t.

Azure DevOps

Ha Azure DevOps tevékenységeket használ, előfordulhat, hogy frissítenie kell a folyamatot az MTP használatára, attól függően, hogy melyik feladatot használja.

VSTest-feladat

Ha a VSTest-feladatot az Azure DevOpsban használja, lecserélheti a .NET Core-feladatra.

.NET Core CLI-feladat

• Ha egyéni arguments került a feladathoz, kövesse a dotnet test áttelepítésére vonatkozó útmutatót.

• Ha a DotNetCoreCLI feladatot használja anélkül, hogy a global.json fájlon keresztül beállítaná a .NET 10 SDK és a későbbi verziók natív MTP-felületét, be kell állítania a arguments feladatot, hogy helyesen irányuljon az eredeti eredménykönyvtárra, valamint a kért TRX-jelentésre. Például:

  - task: DotNetCoreCLI@2
    displayName: Run unit tests
    inputs:
      command: 'test'
      arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
  

  A példában szereplő tesztalkalmazásokat regisztrálni Microsoft.Testing.Extensions.TrxReportkell. Adja hozzá közvetlenül a csomagot, vagy használjon egy teszt SDK-konfigurációt vagy profilt, amely tartalmazza azt.

Viselkedési különbségek a VSTest és az MTP között

Nulla teszt futtatása

Ha egy tesztszerelvény nulla tesztet futtatott, a VSTest ezt tolerálja, és sikeresen kilép. Az MTP azonban a 8-es kilépési kóddal meghiúsul. Ezt többféleképpen is megkerülheti:

• Adja meg a --ignore-exit-code 8 paramétert a tesztek futtatásakor.

• Ha figyelmen kívül szeretné hagyni egy adott tesztprojekt kilépési kódját, adja hozzá a következőket a projektfájlhoz:

  <PropertyGroup>
    <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
  </PropertyGroup>
  

• Használja a környezeti változót TESTINGPLATFORM_EXITCODE_IGNORE .

Console.InputEncoding megőrzése

Ha olyan konzolon futtatja a teszteket, ahol a kódlap explicit módon módosult (például Azure DevOps a kódlap 65001-es értékre van állítva, amely megfelel az UTF8-nak), a viselkedés eltérő lehet a VSTest és az MTP között.

• Az MTP-vel ez a kódolás mindig megmarad.
• Ha a VSTest nem elszigetelt módban fut (a vstest.console alapértelmezett viselkedése), a kódolás megmarad, hasonlóan az MTP-hez.
• Ha a VSTest elkülönítési módban fut (az alapértelmezett viselkedés), dotnet testa kódolás nem marad meg a testhostban, amely a teszteket futtató folyamat.

Jótanács

A kódolás nem kerül megőrzésre a VSTest elkülönítési módban, mert a testhost folyamat ezzel indítható CreateNoWindow = true. Tehát nincs csatlakoztatva az eredeti konzolhoz.

Ha olyan teszttel rendelkezik, amely egy újabb gyermekfolyamatot indít el, és átirányítja a szabványos kimenetét, problémákat tapasztalhat, ha az alábbiak érvényesek:

• A konzol kódlapja 65001 (UTF8) értékre van állítva. Ez a CI-n is előfordulhat, de általában nem helyben. Ha a tesztek futtatása előtt a CI-hez hasonló helyi viselkedést szeretne elérni, futtassa a chcp 65001.
• A gyermekfolyamat nem UTF8 kódolással kezdődik. Ez akkor is előfordulhat, ha a saját tesztje is beállítja a CreateNoWindow = true.

Ez különösen akkor problémás, ha a gyermekfolyamat nem számít az UTF8 BOM (Byte-Order-Mark) bájtra, amelyet a .NET-keretrendszer előző forgatókönyvében kaphat.

Mivel ez a viselkedésbeli különbség valószínűleg problémás lehet kifejezetten a BOM bájt esetében, kerülő megoldásként az InputEncodingot a szerelvény inicializálása során UTF8-ra kell állítani BOM nélkül:

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Egy alternatív megoldás az, hogy ne használjuk a CreateNoWindow = true-t a szabványos bemenetet átirányító gyermekfolyamatokhoz.