Migrera från VSTest till Microsoft. Testing.Platform (MTP)

I den här artikeln får du lära dig hur du migrerar från VSTest till MTP.

Den här artikeln fokuserar på migreringssteg och argumentmappning.

Om du fortfarande behöver välja en plattform börjar du med Översikt över testplattformar.

Om du behöver detaljerad funktion för dotnet test lägen kan du läsa Testa med dotnet test.

Om du behöver en enda lista över kommandoradsalternativ för plattform och tillägg kan du läsa referens för MTP CLI-alternativ.

Anmäl dig för att använda MTP

Det första steget i migreringen är att välja att använda MTP.

För alla testramverk lägger du till <OutputType>Exe</OutputType> i alla testprojekt i lösningen. Därefter följer du den ramverksspecifika vägledningen.

MSTest

MTP stöds av MSTest från och med 3.2.0. Vi rekommenderar dock att du uppdaterar till den senaste tillgängliga MSTest-versionen.

Om du vill anmäla dig, lägg till <EnableMSTestRunner>true</EnableMSTestRunner> under en PropertyGroup i Directory.Build.props-filen.

NUnit

MTP stöds av NUnit3TestAdapter från och med 5.0.0.

Om du vill anmäla dig, lägg till <EnableNUnitRunner>true</EnableNUnitRunner> under en PropertyGroup i Directory.Build.props-filen.

xUnit.net

MTP stöds från och med xunit.v3.

Om du vill anmäla dig, lägg till <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> under en PropertyGroup i Directory.Build.props-filen.

dotnet test

Anmäl dig för .NET 9 SDK och tidigare

I .NET 9 SDK och tidigare finns det inget native stöd för MTP för dotnet test. Supporten bygger på VSTest-infrastrukturen. Om du vill använda det lägger du till <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> under en PropertyGroup i-fil Directory.Build.props .

Anmäl dig för .NET 10 SDK och senare

Från och med .NET 10 SDK finns det native stöd för MTP. Om du vill använda den måste du ange testkörare som Microsoft.Testing.Platform i global.json:

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

Uppdatera dotnet test anrop

Kommandoradsalternativen dotnet test för är indelade i två kategorier: byggrelaterade argument och testrelaterade.

De byggrelaterade argumenten är irrelevanta för testplattformen och behöver därför inte uppdateras för den nya plattformen. Byggrelaterade argument visas här:

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

Testrelaterade argument är VSTest-specifika och måste därför transformeras för att matcha den nya plattformen. I följande tabell visas mappningen mellan VSTest-argumenten och den nya plattformen:

--collect

--collect är en allmän utökningspunkt i VSTest för alla datainsamlare. Utökningsmodellen för MTP är annorlunda och det finns inget sådant centraliserat argument som ska användas av alla datainsamlare. Med MTP kan varje datainsamlare lägga till ett eget kommandoradsalternativ. Att till exempel köra Microsoft CodeCoverage via VSTest kan likna följande:

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

Med MTP blir detta:

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

--filter

--filter är det VSTest-baserade filtret.

MSTest och NUnit stöder samma filterformat även när de körs med MTP.

xUnit.net stöder inte samma filterformat när du kör med MTP. Du måste migrera från det VSTest-baserade filtret till det nya filterstödet i xunit.v3, som tillhandahålls med hjälp av följande kommandoradsalternativ.

xUnit.net specifika alternativ:

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

Mer information finns i Dokumentationen om Microsoft.Testing.Platform för xUnit.net och Frågefilterspråk för xUnit.net.

--logger

Det som vanligtvis kallades "logger" i VSTest kallas "reporter" i MTP. I MTP är loggning uttryckligen endast för diagnostisering.

--collect och --logger är allmänna utökningspunkter i VSTest för alla loggare (eller i samband med MTP, någon reporter). Varje MTP-reporter kan lägga till ett eget kommandoradsalternativ och därför finns det inget centraliserat kommandoradsalternativ som VSTests --logger.

En av de mycket vanliga VSTest-loggarna är TRX-loggaren. Den här loggaren anropas vanligtvis på följande sätt:

dotnet test --logger trx

Med MTP blir kommandot:

dotnet test --report-trx

--settings

VSTest's --settings används för att specificera en RunSettings-fil för testkörningen. RunSettings stöds inte av MTP-kärnan och ersattes av en modernare testconfig.json konfigurationsfil. MSTest och NUnit stöder dock fortfarande de gamla RunSettings när du kör MTP och --settings stöds fortfarande.

vstest.console.exe

Om du använder vstest.console.exe direkt rekommenderar vi att du ersätter det med dotnet test kommandot .

Testutforskaren

När du använder Visual Studio eller Visual Studio Code Test Explorer kan du behöva aktivera stöd för MTP.

Visual Studio

Visual Studio Test Explorer stöder MTP från och med version 17.14. Om du använder en tidigare version kan du behöva uppdatera Visual Studio till den senaste versionen.

Visual Studio Code

Visual Studio Code med C# DevKit stöder MTP.

Azure DevOps

När du använder Azure DevOps uppgifter kan du behöva uppdatera din pipeline för att använda MTP, beroende på vilken uppgift du använder.

VSTest-uppgift

Om du använder VSTest-uppgiften i Azure DevOps kan du ersätta den med .NET Core-aktiviteten.

.NET Core CLI-uppgift

• Om du har anpassat arguments för uppgiften följer du samma vägledning för dotnet test migrering.

• Om du använder uppgiften DotNetCoreCLI utan att välja den inbyggda MTP-upplevelsen för .NET 10 SDK och senare via filen global.json, så måste du ange uppgiften arguments så att den korrekt pekar på katalogen för de resultat som den tidigare pekade på, samt den begärda TRX-rapporten. Till exempel:

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

Beteendeskillnader mellan VSTest och MTP

Utföra ingen test

Om en testsammansättning körde noll tester tolererar VSTest det och avslutas med framgång. MTP misslyckas dock med slutkod 8. Det finns flera sätt att kringgå detta:

• Godkänn --ignore-exit-code 8 när du kör dina tester.

• Om du vill ignorera slutkoden för ett specifikt testprojekt lägger du till följande i projektfilen:

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

• TESTINGPLATFORM_EXITCODE_IGNORE Använd miljövariabeln.

Console.InputEncoding bevarande

Om du kör dina tester i en konsol där kodsidan uttryckligen ändrades (till exempel i Azure DevOps är kodsidan inställd på 65001 som motsvarar UTF8), kan beteendet skilja sig mellan VSTest och MTP.

• Med MTP bevaras alltid den kodningen.
• Eftersom VSTest inte körs i isoleringsläge (standardbeteendet för vstest.console) bevaras kodningen, ungefär som MTP.
• När VSTest körs i isoleringsläge (standardbeteendet dotnet testför ) bevaras inte kodningen i testhosten, vilket är den process som kör testerna.

Om du har ett test som startar ännu en underordnad process och omdirigerar dess standardutdata kan det uppstå problem om följande gäller:

• Konsolens kodsida är inställd på 65001 (UTF8). Detta kan vara fallet på CI men i allmänhet inte lokalt. Om du vill få ett lokalt beteende som liknar i CI kör du chcp 65001 innan du kör testerna.
• Barnprocessen startas med icke-UTF8-teckenkodning. Detta kan också inträffa om ditt eget test också anger CreateNoWindow = true.

Detta är särskilt problematiskt när den underordnade processen inte förväntar sig att se UTF8 BOM (Byte Order Mark) byte, som kan dyka upp i ett tidigare scenario med .NET Framework.

Eftersom denna skillnad i beteende sannolikt är problematisk specifikt för bombytet, kan en lösning vara att ange InputEncoding till UTF-8 utan BOM under samlingsinitieringen.

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

En annan lösning för det är att inte använda CreateNoWindow = true för underordnade processer som omdirigerar standardindata.