Migreren van VSTest naar Microsoft. Testing.Platform (MTP)

In dit artikel leert u hoe u migreert van VSTest naar MTP.

Dit artikel is gericht op migratiestappen en argumentatiemapping.

Als u nog steeds een platform moet kiezen, begint u met het overzicht van testplatforms.

Als u het gedetailleerde gedrag van dotnet test-modi nodig hebt, raadpleegt u Testen met dotnet test.

Als u één lijst met opdrachtregelopties voor platform en extensie nodig hebt, raadpleegt u de naslaginformatie over MTP CLI-opties.

Aanmelden om MTP te gebruiken

De eerste stap in de migratie is het aanmelden voor het gebruik van MTP.

Voeg voor alle testframeworks toe <OutputType>Exe</OutputType> aan alle testprojecten in de oplossing. Volg daarna de frameworkspecifieke richtlijnen.

MSTest

MTP wordt ondersteund door MSTest vanaf 3.2.0. Het is echter raadzaam om bij te werken naar de nieuwste beschikbare MSTest-versie.

Als u zich wilt aanmelden, voegt u <EnableMSTestRunner>true</EnableMSTestRunner> toe onder een PropertyGroup in het Directory.Build.props bestand.

Opmerking

Wanneer u MSTest.Sdk gebruikt, wordt MTP standaard gebruikt, tenzij <UseVSTest>true</UseVSTest> dit is opgegeven.

NUnit

MTP wordt ondersteund door NUnit3TestAdapter vanaf 5.0.0.

Als u zich wilt aanmelden, voegt u <EnableNUnitRunner>true</EnableNUnitRunner> toe onder een PropertyGroup in het Directory.Build.props bestand.

xUnit.net

MTP wordt ondersteund vanaf xunit.v3.

Als u zich wilt aanmelden, voegt u <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> toe onder een PropertyGroup in het Directory.Build.props bestand.

dotnet test

Aanmelden voor deelname aan .NET 9 SDK en eerder

In .NET 9 SDK en eerder is er geen natieve ondersteuning voor MTP voor dotnet test. Ondersteuning is gebouwd op basis van de VSTest-infrastructuur. Om dat te gebruiken, voegt u <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> toe onder een PropertyGroup in het Directory.Build.props bestand.

Belangrijk

Wanneer u MTP-ondersteuning in deze modus uitvoert, moet u -- toevoegen om de argumenten van de nieuwe platformargumenten te scheiden dotnet test. Bijvoorbeeld: dotnet test --no-build -- --list-tests.

Aanmelden voor .NET 10 SDK en hoger

Vanaf .NET 10 SDK is er native ondersteuning voor MTP. Als u deze wilt gebruiken, moet u de testrunner opgeven zoals Microsoft.Testing.Platform in global.json:

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

Belangrijk

In deze modus wordt de extra -- niet meer gebruikt.

Aanroepen dotnet test bijwerken

Opdrachtregelopties van dotnet test zijn onderverdeeld in twee categorieën: build-gerelateerde argumenten en test-gerelateerde argumenten.

De argumenten met betrekking tot de build zijn niet relevant voor het testplatform en hoeven daarom niet te worden bijgewerkt voor het nieuwe platform. Hier worden argumenten met betrekking tot build weergegeven:

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

De testgerelateerde argumenten zijn specifiek voor VSTest en moeten dus worden getransformeerd om overeen te komen met het nieuwe platform. In de volgende tabel ziet u de toewijzing tussen de VSTest-argumenten en het nieuwe platform:

VSTest-argument Nieuw platform-argument
--test-adapter-path <ADAPTER_PATH> Niet relevant voor MTP
--blame Niet relevant voor MTP
--blame-crash --crashdump (vereist Crash Dump Extensie)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (vereist Crash Dump Extensie)
--blame-crash-collect-always Niet ondersteund
--blame-hang --hangdump (vereist hangdumpextensie)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (vereist hangdumpextensie)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (vereist hangdumpextensie)
--collect <DATA_COLLECTOR_NAME> Afhankelijk van de gegevensverzamelaar
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Is afhankelijk van het geselecteerde testframework
-l\|--logger <LOGGER> Afhankelijk van de logger
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Is afhankelijk van het geselecteerde testframework
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (geleverd door VSTestBridge)

--collect

--collect is een algemeen uitbreidbaarheidspunt in VSTest voor elke gegevensverzamelaar. Het uitbreidbaarheidsmodel van MTP verschilt en er is geen gecentraliseerd argument dat door alle gegevensverzamelaars moet worden gebruikt. Met MTP kan elke gegevensverzamelaar een eigen opdrachtregeloptie toevoegen. Het uitvoeren van Microsoft CodeCoverage via VSTest is bijvoorbeeld vergelijkbaar met het volgende:

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

Met MTP wordt dit:

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

Belangrijk

Zoals eerder uitgelegd, is bij het gebruik van MTP met VSTest dotnet test extra -- nodig voordat de argumenten die bedoeld zijn om aan het platform te worden doorgegeven. Dus, dit wordt dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter is het VSTest-filter.

MSTest en NUnit ondersteunen dezelfde filterindeling, zelfs wanneer deze wordt uitgevoerd met MTP.

xUnit.net biedt geen ondersteuning voor dezelfde filterindeling wanneer deze wordt uitgevoerd met MTP. U moet migreren van het op VSTest gebaseerde filter naar de nieuwe filterondersteuning in xunit.v3, die wordt geleverd met behulp van de volgende opdrachtregelopties.

xUnit.net specifieke opties:

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

Zie de documentatie van Microsoft.Testing.Platform voor xUnit.net en queryfiltertaal voor xUnit.net voor meer informatie.

--logger

Wat meestal 'logger' in VSTest wordt genoemd, wordt 'reporter' genoemd in MTP. In MTP is logboekregistratie expliciet bedoeld voor diagnosedoeleinden.

Vergelijkbaar met --collect, --logger is een algemeen uitbreidbaarheidspunt in VSTest voor elke logger (of, in de context van MTP, elke reporter). Elke MTP-reporter is vrij om een eigen commandoregeloptie toe te voegen, en er is daarom geen gecentraliseerde commandoregeloptie zoals bij VSTest --logger.

Een van de veelgebruikte VSTest loggers is de TRX logger. Deze logger wordt meestal als volgt aangeroepen:

dotnet test --logger trx

Met MTP wordt de opdracht:

dotnet test --report-trx

Belangrijk

Als u wilt gebruiken --report-trx, moet het Microsoft.Testing.Extensions.TrxReport NuGet-pakket zijn geïnstalleerd.

Belangrijk

Zoals eerder uitgelegd, is bij het gebruik van MTP met VSTest dotnet test extra -- nodig voordat de argumenten aan het platform worden doorgegeven. Dus, dit wordt dotnet test -- --report-trx.

--settings

VSTest --settings wordt gebruikt om een RunSettings-bestand op te geven voor de testuitvoering. RunSettings wordt niet ondersteund door de kern-MTP en is vervangen door een moderner testconfig.json configuratiebestand. MSTest en NUnit ondersteunen echter nog steeds de oude RunSettings bij het uitvoeren van MTP en --settings worden nog steeds ondersteund.

vstest.console.exe

Als u rechtstreeks gebruikt vstest.console.exe , raden we u aan deze te vervangen door de dotnet test opdracht.

Test Explorer

Wanneer u Visual Studio of Visual Studio Code Test Explorer gebruikt, moet u mogelijk de ondersteuning voor MTP inschakelen.

Visual Studio

Visual Studio Test Explorer ondersteunt MTP vanaf versie 17.14. Als u een eerdere versie gebruikt, moet u visual studio mogelijk bijwerken naar de nieuwste versie.

Visual Studio Code

Visual Studio Code met C# DevKit ondersteunt MTP.

Azure DevOps

Wanneer u Azure DevOps taken gebruikt, moet u mogelijk uw pijplijn bijwerken om MTP te gebruiken, afhankelijk van de taak die u gebruikt.

VSTest-taak

Als u de VSTest-taak in Azure DevOps gebruikt, kunt u deze vervangen door de .NET Core-taak.

.NET Core CLI-taak

  • Als u een aangepaste arguments naar de taak hebt doorgegeven, volgt u dezelfde richtlijnen voor dotnet test migratie.

  • Als u de taak DotNetCoreCLI gebruikt zonder te kiezen voor de systeemeigen MTP-ervaring voor .NET 10 SDK en hoger via het global.json-bestand, moet u de taak arguments zo instellen dat deze correct naar de map met resultaten verwijst die eerder werd gebruikt, evenals het aangevraagde TRX-rapport. Voorbeeld:

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

Gedragsverschillen tussen VSTest en MTP

Nultests uitvoeren

Als een testassembly geen tests heeft uitgevoerd, accepteert VSTest dat en sluit succesvol af. MTP mislukt echter met afsluitcode 8. Er zijn meerdere manieren om dit te omzeilen:

  • Passeer --ignore-exit-code 8 wanneer u uw tests uitvoert.

  • Als u deze afsluitcode voor een specifiek testproject wilt negeren, voegt u het volgende toe aan het projectbestand:

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

  • Gebruik de TESTINGPLATFORM_EXITCODE_IGNORE omgevingsvariabele.

Behoud van Console.InputEncoding

Als u uw tests uitvoert in een console waarin de codepagina expliciet is gewijzigd (bijvoorbeeld in Azure DevOps, wordt de codepagina ingesteld op 65001 die overeenkomt met UTF8), kan het gedrag verschillen tussen VSTest en MTP.

  • Met MTP blijft die codering altijd behouden.
  • Als VSTest niet wordt uitgevoerd in de isolatiemodus (het standaardgedrag van vstest.console), blijft die codering behouden, vergelijkbaar met MTP.
  • Als VSTest wordt uitgevoerd in de isolatiemodus (het standaardgedrag van dotnet test), blijft die codering niet behouden in de testhost. Dit is het proces waarmee de tests worden uitgevoerd.

Aanbeveling

De reden dat de codering niet behouden blijft met de VSTest-isolatiemodus, is dat het testhost-proces wordt gestart met CreateNoWindow = true. Het is dus niet gekoppeld aan de oorspronkelijke console.

Als u een test hebt die een ander onderliggend proces start en de standaarduitvoer omleidt, kunt u problemen ondervinden als al het volgende van toepassing is:

  • De consolecodepagina is ingesteld op 65001 (UTF8). Dit kan het geval zijn bij Continuous Integration (CI), maar over het algemeen niet lokaal. Als u gedrag lokaal wilt krijgen dat vergelijkbaar is met dat in CI, voert u chcp 65001 uit voordat u de tests uitvoert.
  • Het subprocess wordt gestart met niet-UTF8-codering. Dit kan ook gebeuren als uw eigen test ook CreateNoWindow = true instelt.

Dit is vooral problematisch wanneer het child process niet verwacht de UTF-8 BOM (Byte-Order-Mark) byte te tegenkomen, zoals het mogelijk kan in het vorige scenario op .NET Framework.

Omdat dit gedragsverschil waarschijnlijk problematisch is voor de BOM-byte, is het een workaround om tijdens de initialisatie van de assembly InputEncoding in te stellen op UTF8 zonder BOM.

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

Een andere tijdelijke oplossing hiervoor is om niet te gebruiken CreateNoWindow = true voor onderliggende processen die standaardinvoer omleiden.

  • Last updated on