Migrieren Sie von VSTest zu Microsoft. Testing.Platform (MTP)

In diesem Artikel erfahren Sie, wie Sie von VSTest zu MTP migrieren.

Dieser Artikel konzentriert sich auf Migrationsschritte und Argumentenstrukturierung.

Wenn Sie noch eine Plattform auswählen müssen, beginnen Sie mit der Übersicht über Testplattformen.

Wenn Sie ein detailliertes Verhalten von dotnet test Modi benötigen, lesen Sie "Testen mit dotnet test".

Wenn Sie eine einzige Liste von Plattform- und Erweiterungs-Befehlszeilenoptionen benötigen, lesen Sie die MTP CLI-Optionsreferenz.

Anmeldung zur Verwendung von MTP

Der erste Schritt bei der Migration besteht darin, sich für die Verwendung von MTP zu entscheiden.

Fügen Sie <OutputType>Exe</OutputType> zu allen Testprojekten in der Lösung für alle Testframeworks hinzu. Folgen Sie danach den frameworkspezifischen Anleitungen.

MSTest

MTP wird von MSTest ab 3.2.0 unterstützt. Es wird jedoch empfohlen, auf die neueste verfügbare MSTest-Version zu aktualisieren.

Um sich anzumelden, fügen Sie <EnableMSTestRunner>true</EnableMSTestRunner> unter einem PropertyGroup in der Directory.Build.props-Datei hinzu.

NUnit

MTP wird von NUnit3TestAdapter ab 5.0.0 unterstützt.

Um sich anzumelden, fügen Sie <EnableNUnitRunner>true</EnableNUnitRunner> unter einem PropertyGroup in der Directory.Build.props-Datei hinzu.

xUnit.net

MTP wird ab xunit.v3 unterstützt.

Um sich anzumelden, fügen Sie <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> unter einem PropertyGroup in der Directory.Build.props-Datei hinzu.

dotnet test

Anmelden für .NET 9 SDK und frühere Versionen

In .NET 9 SDK und früheren Versionen gibt es keine native Unterstützung für MTP für dotnet test. Der Support basiert auf der VSTest-Infrastruktur. Um dies zu verwenden, fügen Sie unter <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> einer PropertyGroup Datei Directory.Build.props hinzu.

Anmelden für .NET 10 SDK und höher

Ab .NET 10 SDK gibt es native Unterstützung für MTP. Um ihn zu verwenden, müssen Sie den Test-Runner als Microsoft.Testing.Platform in global.json angeben.

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

Aktualisierung von dotnet test-Aufrufen

Befehlszeilenoptionen dotnet test sind in zwei Kategorien unterteilt: build-bezogene Argumente und test-bezogene Argumente.

Die buildbezogenen Argumente sind für die Testplattform irrelevant und müssen daher nicht für die neue Plattform aktualisiert werden. Hier sind die build-bezogenen Argumente aufgeführt:

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

Die testbezogenen Argumente sind VSTest-spezifisch und müssen daher so transformiert werden, dass sie der neuen Plattform entsprechen. Die folgende Tabelle zeigt die Zuordnung zwischen den VSTest-Argumenten und der neuen Plattform:

--collect

--collect ist ein allgemeiner Erweiterbarkeitspunkt in VSTest für jeden Datensammler. Das Erweiterbarkeitsmodell von MTP unterscheidet sich und es gibt kein solches zentrales Argument, das von allen Datensammlern verwendet werden soll. Mit MTP kann jeder Datensammler eine eigene Befehlszeilenoption hinzufügen. Das Ausführen von Microsoft CodeCoverage über VSTest kann z. B. wie folgt aussehen:

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

Mit MTP wird dies zu:

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

--filter

--filter ist der VSTest-basierte Filter.

MSTest und NUnit unterstützen dasselbe Filterformat auch bei der Ausführung mit MTP.

xUnit.net unterstützt nicht dasselbe Filterformat bei der Ausführung mit MTP. Sie müssen vom VSTest-basierten Filter zur neuen Filterunterstützung in xunit.v3 migrieren, die mithilfe der folgenden Befehlszeilenoptionen bereitgestellt wird.

xUnit.net spezifischen Optionen:

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

Weitere Informationen finden Sie in der Dokumentation zu Microsoft.Testing.Platform für xUnit.net und Abfragefiltersprache für xUnit.net.

--logger

Was in der Regel als "Logger" in VSTest bezeichnet wurde, wird als "Reporter" in MTP bezeichnet. In MTP ist die Protokollierung nur für Diagnosezwecke explizit vorgesehen.

Ähnlich wie --collect, --logger ist ein allgemeiner Erweiterbarkeitspunkt in VSTest für jeden Logger (oder im Kontext von MTP, jeder Reporter). Jeder MTP-Reporter kann eine eigene Befehlszeilenoption hinzufügen, und so gibt es keine zentrale Befehlszeilenoption wie VSTest.--logger

Einer der häufig verwendeten VSTest-Logger ist der TRX-Logger. Dieser Logger wird in der Regel wie folgt aufgerufen:

dotnet test --logger trx

Mit MTP lautet der Befehl:

dotnet test --report-trx

--settings

VSTest's --settings wird verwendet, um eine RunSettings-Datei für die Testausführung anzugeben. RunSettings wird vom Kern-MTP nicht unterstützt und wurde durch eine modernere testconfig.json Konfigurationsdatei ersetzt. MSTest und NUnit unterstützen jedoch weiterhin die alten RunSettings beim Ausführen von MTP und --settings werden weiterhin unterstützt.

vstest.console.exe

Wenn Sie direkt verwenden vstest.console.exe , empfehlen wir, sie durch den dotnet test Befehl zu ersetzen.

Test-Explorer

Wenn Sie Visual Studio oder Visual Studio Code Test-Explorer verwenden, müssen Sie möglicherweise die Unterstützung für MTP aktivieren.

Visual Studio

Visual Studio Test-Explorer unterstützt MTP ab Version 17.14. Wenn Sie eine frühere Version verwenden, müssen Sie Möglicherweise Ihr Visual Studio auf die neueste Version aktualisieren.

Visual Studio Code

Visual Studio Code mit C# DevKit unterstützt MTP.

Azure DevOps

Wenn Sie Azure DevOps Aufgaben verwenden, müssen Sie ihre Pipeline möglicherweise aktualisieren, um MTP zu verwenden, je nachdem, welche Aufgabe Sie verwenden.

VSTest-Aufgabe

Wenn Sie die VSTest-Aufgabe in Azure DevOps verwenden, können Sie sie durch die .NET Core-Aufgabe ersetzen.

.NET Core CLI-Aufgabe

• Wenn Sie benutzerdefinierte arguments an die Aufgabe übergeben haben, befolgen Sie die gleichen Anleitungen für die dotnet test-Migration.

• Wenn Sie die Aufgabe DotNetCoreCLI verwenden, ohne sich für das native MTP-Erlebnis für das .NET 10 SDK und höher über die global.json-Datei zu entscheiden, müssen Sie die Aufgabe arguments so einstellen, dass sie wieder korrekt auf das Ergebnisverzeichnis verweist, sowie auf den angeforderten TRX-Bericht. Beispiel:

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

Verhaltensunterschiede zwischen VSTest und MTP

Ausführen von Nulltests

Wenn eine Testassembly keine Tests ausgeführt hat, toleriert VSTest dies und wird erfolgreich beendet. MTP schlägt jedoch mit Beendigungscode 8 fehl. Es gibt mehrere Möglichkeiten, dies zu umgehen:

• Geben Sie --ignore-exit-code 8 an, wenn Sie Ihre Tests ausführen.

• Wenn Sie diesen Exitcode für ein bestimmtes Testprojekt ignorieren möchten, fügen Sie Folgendes in der Projektdatei hinzu:

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

• Verwenden Sie die TESTINGPLATFORM_EXITCODE_IGNORE Umgebungsvariable.

Console InputEncoding-Beibehaltung

Wenn Sie Ihre Tests in einer Konsole ausführen, in der die Codepage explizit geändert wurde (z. B. in Azure DevOps, wird die Codepage auf 65001 festgelegt, die UTF8 entspricht), kann das Verhalten zwischen VSTest und MTP unterschiedlich sein.

• Bei MTP wird diese Codierung immer beibehalten.
• Wenn VSTest nicht im Isolationsmodus ausgeführt wird (das Standardverhalten von vstest.console), wird diese Codierung beibehalten, ähnlich wie MTP.
• Wenn VSTest im Isolationsmodus ausgeführt wird (standardverhalten von dotnet test), wird diese Codierung nicht im Testhost beibehalten, d. h. der Prozess, der die Tests ausführt.

Wenn Sie einen Test haben, der einen weiteren untergeordneten Prozess startet und seine Standardausgabe umleitet, können Probleme auftreten, wenn alle folgenden zutreffen:

• Die Konsolencodepage ist auf 65001 (UTF8) festgelegt. Dies kann bei CI der Fall sein, aber im Allgemeinen nicht lokal. Um ein lokales Verhalten ähnlich wie in CI zu erreichen, führen Sie chcp 65001 aus, bevor Sie die Tests ausführen.
• Der untergeordnete Prozess wird mit einer nicht-UTF8-Codierung gestartet. Dies kann auch passieren, wenn Ihr eigener Test auch CreateNoWindow = true festlegt.

Dies ist besonders problematisch, wenn der untergeordnete Prozess nicht erwartet, dass das UTF8 BOM (Byte-Order-Mark)-Byte auftaucht, was im vorherigen Szenario im .NET Framework passieren kann.

Da dieser Verhaltensunterschied wahrscheinlich speziell für das BOM-Byte problematisch ist, besteht eine Problemumgehung darin, "InputEncoding" während der Assemblyinitialisierung auf UTF8 ohne BOM festzulegen:

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

Eine andere Problemumgehung besteht darin, CreateNoWindow = true nicht für untergeordnete Prozesse zu verwenden, die die Standardeingabe umleiten.