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.

Tips/Råd

Om du vill automatisera en migrering av ett helt lagringsplatsinnehåll med en AI-kodningsassistent, installera plugin-programmen dotnet-test och dotnet-test-migration från .NET Agent Skills. Be test-migration agenten att upptäcka och migrera din testkonfiguration, eller anropa migrate-vstest-to-mtp färdigheten för just den här migreringen. Granska de genererade ändringarna innan du sammanfogar dem.

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.

Anmärkning

När du använder MSTest.Sdk används MTP som standard, såvida inte <UseVSTest>true</UseVSTest> anges.

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 .

Viktigt!

När du kör MTP-stöd i det här läget måste du lägga -- till för att separera argumenten dotnet test från de nya plattformsargumenten. Till exempel dotnet test --no-build -- --list-tests.

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"
  }
}

Viktigt!

I det här läget krävs inte längre extra -- . Behåll det för att vidarebefordra testprogramargument otvetydigt.

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>

Även om --arch det fortfarande är ett byggrelaterat alternativ ersätter det arkitekturen som VSTest väljer via RunConfiguration.TargetPlatform. Skicka --arch till själva dotnet test, före en eventuell ---avgränsare.

Migrera till exempel det här VSTest-projektkommandot:

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

Använd följande MTP-kommando för .NET 10 SDK och senare versioner:

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

Ersätt x86 med x64 för att rikta in dig på x64. MTP kör testmoduler parallellt som standard, så /Parallel behöver ingen ersättning. Om du vill begränsa parallellitet på modulnivå använder du --max-parallel-test-modules <NUMBER>.

Viktigt!

Du kan inte kombinera --solution med --arch, --oseller --runtime. De här alternativen anges RuntimeIdentifier som en global MSBuild-egenskap, och lösningsversioner stöder inte en global RuntimeIdentifier. Om du vill testa en lösning mellan arkitekturer anropar du varje testprojekt separat eller anger RuntimeIdentifier i de enskilda testprojekten.

Ersätt till exempel dessa fyra VSTest-kommandon på lösningsnivå:

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

För .NET 10 SDK och senare versioner använder du en matris på projektnivå:

$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."
}

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:

VSTest-argument	Nytt plattformsargument
`--test-adapter-path <ADAPTER_PATH>`	Inte relevant för MTP
`--blame`	Inte relevant för MTP
`--blame-crash`	`--crashdump` (kräver tillägg för kraschdumpar)
`--blame-crash-dump-type <DUMP_TYPE>`	`--crashdump-type` (kräver tillägg för kraschdumpar)
`--blame-crash-collect-always`	Stöds inte
`--blame-hang`	`--hangdump` (kräver tillägg för hängdump)
`--blame-hang-dump-type <DUMP_TYPE>`	`--hangdump-type` (kräver tillägg för hängdump)
`--blame-hang-timeout <TIMESPAN>`	`--hangdump-timeout` (kräver tillägg för hängdump)
`--collect <DATA_COLLECTOR_NAME>`	Beror på datainsamlaren
`-d\\|--diag <LOG_FILE>`	`--diagnostic`
`--filter <EXPRESSION>`	Beror på det valda testramverket
`-l\\|--logger <LOGGER>`	Beror på loggaren
`--results-directory <RESULTS_DIR>`	`--results-directory <RESULTS_DIR>`
`-s\\|--settings <SETTINGS_FILE>`	Beror på det valda testramverket
`-t\\|--list-tests`	`--list-tests`
`-- RunConfiguration.TargetPlatform=<ARCHITECTURE>`	`--arch <ARCHITECTURE>` för ett projektanrop
`/Parallel`	Inget alternativ krävs. MTP kör testmoduler parallellt som standard.
`-- <RunSettings arguments>`	`--test-parameter` (tillhandahålls av VSTestBridge)

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

Viktigt!

Om du vill använda --coveragemåste varje måltestprogram referera till Microsoft.Testing.Extensions.CodeCoverage NuGet-paketet direkt eller via en test-SDK-konfiguration eller profil som innehåller det.

Viktigt!

Som vi förklarade tidigare, när du använder MTP med VSTest-baserade dotnet test behövs extra -- före de argument som är avsedda att skickas till plattformen. Det här blir alltså 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.

Tips/Råd

Om din lösning blandar testramverk som använder olika filtersyntaxer (till exempel MSTest och xUnit.net) kan du villkorligt dirigera ramverksspecifika argument med hjälp av TestingPlatformCommandLineArguments egenskapen MSBuild. Mer information finns i Lösningar med blandade testramverk eller tillägg.

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

Viktigt!

Om du vill använda --report-trxmåste varje måltestprogram referera till Microsoft.Testing.Extensions.TrxReport NuGet-paketet direkt eller via en test-SDK-konfiguration eller profil som innehåller det.

Viktigt!

GitHub Actions reporteralternativ är paketspecifika och är inte utbytbara:

Reporterpaket	MTP-alternativ
Microsoft. Testing.Extensions.GitHubActionsReport	`--report-gh`
GitHubActionsTestLogger	`--report-github`

Testprogrammet känner bara igen ett alternativ när paketet som äger det är installerat och registrerat. Om du till exempel migrerar --logger GitHubActions och behåller GitHubActionsTestLogger paketet ersätter du VSTest-kommandot:

dotnet test --logger GitHubActions

Använd .NET 10 SDK och senare versioner:

dotnet test --report-github

För .NET 9 SDK:t och tidigare versioner använder du dotnet test -- --report-github i stället.

`--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)'
```
Testprogrammen i det här exemplet måste registrera Microsoft.Testing.Extensions.TrxReport. Lägg till paketet direkt eller använd en test-SDK-konfiguration eller profil som innehåller det.

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.

Tips/Råd

Anledningen till att kodningen inte bevaras med VSTest-isoleringsläget är att testhost-processen startas med CreateNoWindow = true. Så den är inte ansluten till den ursprungliga konsolen.

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.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-08-31

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

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

MSTest

NUnit

xUnit.net

dotnet test

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

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

Uppdatera dotnet test anrop

--collect

--filter

--logger

--settings

vstest.console.exe

Testutforskaren

Visual Studio

Visual Studio Code

Azure DevOps

VSTest-uppgift

.NET Core CLI-uppgift

Beteendeskillnader mellan VSTest och MTP

Utföra ingen test

Console.InputEncoding bevarande

Feedback

Ytterligare resurser

`dotnet test`

Uppdatera `dotnet test` anrop

`--collect`

`--filter`

`--logger`

`--settings`

`vstest.console.exe`