Migrace z VSTest na Microsoft Testing.Platform (MTP)

V tomto článku se dozvíte, jak migrovat z VSTest na MTP.

Tento článek se zaměřuje na kroky migrace a mapování argumentů.

Pokud stále potřebujete zvolit platformu, začněte přehledem testovacích platforem.

Pokud potřebujete podrobné chování dotnet test režimů, přečtěte si téma Testování pomocí dotnet test.

Pokud potřebujete jeden seznam možností příkazového řádku platformy a rozšíření, přečtěte si referenční informace o možnostech rozhraní příkazového řádku MTP.

Výslovný souhlas s používáním MTP

Prvním krokem v migraci je vyjádření souhlasu s používáním MTP.

Pro všechny testovací architektury přidejte <OutputType>Exe</OutputType> do všech testovacích projektů v řešení. Potom postupujte podle pokynů specifických pro danou architekturu.

MSTest

MsTest podporuje MTP počínaje verzí 3.2.0. Doporučujeme ale aktualizovat na nejnovější dostupnou verzi MSTest.

Pokud se chcete přihlásit, přidejte <EnableMSTestRunner>true</EnableMSTestRunner> pod PropertyGroup v souboru Directory.Build.props.

Poznámka:

Pokud používáte MSTest.Sdk, použije se MTP ve výchozím nastavení, pokud <UseVSTest>true</UseVSTest> není zadán.

NUnit

MTP podporuje NUnit3TestAdapter od verze 5.0.0.

Pokud se chcete přihlásit, přidejte <EnableNUnitRunner>true</EnableNUnitRunner> pod PropertyGroup v souboru Directory.Build.props.

xUnit.net

MTP se podporuje od xunit.v3.

Pokud se chcete přihlásit, přidejte <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> pod PropertyGroup v souboru Directory.Build.props.

dotnet test

Výslovný souhlas se sadou .NET 9 SDK a staršími verzemi

V .NET 9 SDK a předchozích verzích neexistuje žádná nativní podpora pro MTP pro . Podpora je založená na infrastruktuře VSTest. Pokud ho chcete použít, přidejte <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> pod PropertyGroup v souboru Directory.Build.props.

Důležité

Při spuštění podpory MTP v tomto režimu je nutné přidat -- pro oddělení dotnet test argumentů od argumentů platformy. Například: dotnet test --no-build -- --list-tests.

Možnost povolit pro .NET 10 SDK a novější

Počínaje .NET 10 SDK existuje nativní podpora MTP. Pokud ho chcete použít, musíte určit spouštěč testů jako Microsoft.Testing.Platform v global.json:

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

Důležité

V tomto režimu se již nadbytečné -- nepoužívá.

Aktualizujte dotnet test vyvolání

Možnosti příkazového dotnet test řádku jsou rozdělené do dvou kategorií: argumenty související s sestavením a testovací argumenty.

Argumenty související s sestavením nejsou pro testovací platformu relevantní a proto není nutné je aktualizovat pro novou platformu. Zde jsou uvedené argumenty související se sestavením:

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

Argumenty související s testováním jsou specifické pro VSTest, takže je potřeba je transformovat tak, aby odpovídaly nové platformě. Následující tabulka ukazuje mapování mezi argumenty VSTest a novou platformou:

Argument VSTest	Nový argument platformy
--test-adapter-path <ADAPTER_PATH>	Není relevantní pro MTP
--blame	Není relevantní pro MTP
--blame-crash	--crashdump (vyžaduje rozšíření výpisu stavu systému)
--blame-crash-dump-type <DUMP_TYPE>	--crashdump-type (vyžaduje rozšíření výpisu stavu systému)
--blame-crash-collect-always	Není podporováno
--blame-hang	--hangdump (vyžaduje rozšíření "Hang Dump")
--blame-hang-dump-type <DUMP_TYPE>	--hangdump-type (vyžaduje rozšíření "Hang Dump")
--blame-hang-timeout <TIMESPAN>	--hangdump-timeout (vyžaduje rozšíření "Hang Dump")
--collect <DATA_COLLECTOR_NAME>	Závisí na sběrači dat.
-d\|--diag <LOG_FILE>	--diagnostic
--filter <EXPRESSION>	Závisí na vybrané testovací rozhraní.
-l\|--logger <LOGGER>	Závisí na protokolovacím nástroji.
--results-directory <RESULTS_DIR>	--results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE>	Závisí na vybrané testovací rozhraní.
-t\|--list-tests	--list-tests
-- <RunSettings arguments>	--test-parameter (poskytuje VSTestBridge)

--collect

--collect je obecný bod rozšiřitelnosti v nástroji VSTest pro všechny kolektory dat. Model rozšiřitelnosti MTP se liší a neexistuje žádný takový centralizovaný argument, který by bylo možné používat ve všech kolekcích dat. S MTP může každý kolektor dat přidat vlastní možnost příkazového řádku. Spuštění Microsoft CodeCoverage prostřednictvím VSTest může být například podobné následujícímu:

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

S MTP se stane toto:

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

Důležité

Jak bylo již vysvětleno, při použití MTP s VSTestem je nutné přidat další dotnet test před argumenty určené pro platformu. Takže se to změní dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter je filtr založený na VSTest.

MSTest a NUnit podporují stejný formát filtru i při spuštění s MTP.

xUnit.net nepodporuje stejný formát filtru při spuštění s MTP. Je nutné provést migraci z filtru založeného na VSTest na novou podporu filtru v xunit.v3, která je k dispozici pomocí následujících možností příkazového řádku.

xUnit.net konkrétní možnosti:

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

Další informace najdete v dokumentaci k platformě Microsoft.Testing.Platform pro xUnit.net a k jazyku dotazovacích filtrů pro xUnit.net.

Tip

Pokud vaše řešení kombinuje testovací architektury, které používají různé syntaxe filtru (například MSTest a xUnit.net), můžete podmíněně směrovat argumenty specifické pro architekturu TestingPlatformCommandLineArguments pomocí vlastnosti MSBuild. Podrobnosti najdete v tématu Řešení se smíšenými testovacími architekturami nebo rozšířeními.

--logger

To, co se obvykle v nástroji VSTest označuje jako "logger," se v MTP označuje jako "reporter." V MTP je protokolování explicitně určené jenom pro účely diagnostiky.

Podobně jako --collect, je --logger obecný bod rozšiřitelnosti v nástroji VSTest pro libovolný protokolovací nástroj (nebo v kontextu MTP, jakýkoli reportér). Každý reportér MTP může přidat vlastní možnost příkazového řádku, a proto neexistuje žádná centralizovaná možnost příkazového řádku, jako je VSTest --logger.

Jedním z velmi běžně používaných protokolovacích nástroj VSTest je protokolovací nástroj TRX. Tento logger se obvykle používá následovně:

dotnet test --logger trx

Pomocí MTP se příkaz změní na:

dotnet test --report-trx

Důležité

Pokud chcete použít --report-trx, musíte mít Microsoft.Testing.Extensions.TrxReport nainstalovaný balíček NuGet.

Důležité

Jak bylo již vysvětleno, při použití MTP s VSTestem je nutné přidat další dotnet test před argumenty určené pro platformu. Takže se to změní dotnet test -- --report-trx.

--settings

VSTest --settings se používá k určení souboru RunSettings pro testovací běh. RunSettings nepodporuje základní MTP a nahradil ho modernější testconfig.json konfigurační soubor. MsTest a NUnit však stále podporují staré RunSettings při spuštění MTP a --settings jsou stále podporovány.

vstest.console.exe

Pokud používáte vstest.console.exe přímo, doporučujeme ho nahradit příkazem dotnet test .

Průzkumník testů

Při použití Visual Studio nebo Visual Studio Code Průzkumníka testů možná budete muset povolit podporu MTP.

Visual Studio

Visual Studio Průzkumník testů podporuje MTP od verze 17.14. Pokud používáte starší verzi, možná budete muset aktualizovat Visual Studio na nejnovější verzi.

Visual Studio Code

Visual Studio Code s C# DevKit podporuje MTP.

Azure DevOps

Při použití Azure DevOps úloh možná budete muset aktualizovat kanál tak, aby používal MTP v závislosti na tom, kterou úlohu používáte.

Úloha VSTest

Pokud v Azure DevOps používáte úlohu VSTest, můžete ji nahradit úlohou .NET Core.

úloha rozhraní příkazového řádku .NET Core

• Pokud jste do úkolu předali vlastní arguments, postupujte podle stejných pokynů pro dotnet test migraci.

• Pokud používáte úlohu DotNetCoreCLI bez aktivace nativní MTP funkce pro .NET 10 SDK a novější prostřednictvím souboru global.json, musíte nastavit úlohu arguments tak, aby správně odkazovala na adresář výsledků, na který dříve odkazoval, a rovněž na požadovaný TRX report. Například:

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

Rozdíly v chování mezi VSTestem a MTP

Spouštění nulových testů

Pokud testovací sestavení spustilo nulové testy, VSTest to toleruje a ukončí se úspěšným výsledkem. MTP ale selže s ukončovacím kódem 8. Existuje několik způsobů, jak to obejít:

• Při spouštění testů použijte --ignore-exit-code 8.

• Pokud chcete tento ukončovací kód pro konkrétní testovací projekt ignorovat, přidejte do souboru projektu následující kód:

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

• Použijte proměnnou TESTINGPLATFORM_EXITCODE_IGNORE prostředí.

Zachování kódování vstupu konzole console.InputEncoding

Pokud spustíte testy v konzole, kde byla explicitně změněna znaková stránka (například v Azure DevOps, je znaková stránka nastavená na 65001, která odpovídá UTF8), chování se může lišit mezi VSTest a MTP.

• U MTP je toto kódování vždy zachováno.
• Pokud VSTest není spuštěný v režimu izolace (výchozí chování vstest.console), toto kódování je zachováno, podobně jako MTP.
• Pokud je VSTest spuštěný v režimu izolace (výchozí chování dotnet test), toto kódování se v testhostu nezachová, což je proces, který spouští testy.

Tip

Důvodem, proč kódování není zachováno v režimu izolace VSTest, je to, že proces testhost je spuštěn s CreateNoWindow = true. Takže není připojen k původní konzole.

Pokud máte test, který spustí další podřízený proces a přesměruje jeho standardní výstup, může dojít k problémům, pokud platí následující:

• Znaková stránka konzoly je nastavená na 65001 (UTF8). Může se to stát v CI, ale obecně ne lokálně. Pokud chcete získat místní chování podobné v CI, spusťte chcp 65001 před spuštěním testů.
• Podřízený proces se spustí s kódováním jiného typu než UTF8. K tomu může dojít také v případě, že váš vlastní test také nastaví CreateNoWindow = true.

To je obzvláště problematické, pokud podřízený proces neočekává přítomnost bajtu UTF8 BOM (Byte-Order-Mark), což může nastat v daném kontextu na platformě .NET Framework.

Vzhledem k tomu, že tento rozdíl v chování je pravděpodobně problematický zejména pro bajt BOM, alternativním řešením je nastavit InputEncoding na UTF8 bez BOM během inicializace sestavení.

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

Jiným řešením je nepoužívat CreateNoWindow = true pro podřízené procesy, které přesměrovávají standardní vstup.