Migrieren von VSTest zu Microsoft.Testing.Platform

In diesem Artikel erfahren Sie, wie Sie von VSTest zu Microsoft.Testing.Platform 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 Referenz zu den Optionen der Microsoft.Testing.Platform CLI.

Melden Sie sich für die Verwendung von Microsoft.Testing.Platform an.

Der erste Schritt bei der Migration besteht darin, sich für die Verwendung von Microsoft.Testing.Platform 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

Microsoft.Testing.Platform 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

Microsoft.Testing.Platform 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

Microsoft.Testing.Platform 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 systemeigene Unterstützung für Microsoft.Testing.Platform 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 systemeigene Unterstützung für Microsoft.Testing.Platform. 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 Microsoft.Testing.Platform unterscheidet sich und es gibt kein solches zentrales Argument, das von allen Datensammlern verwendet werden soll. Mit Microsoft.Testing.Platform 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 Microsoft.Testing.Platform wird dies zu:

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

--filter

--filter ist der VSTest-basierte Filter.

MSTest und NUnit unterstützen das gleiche Filterformat, auch wenn sie mit Microsoft.Testing.Platform ausgeführt wird.

xUnit.net unterstützt nicht dasselbe Filterformat, wenn es mit Microsoft.Testing.Platform ausgeführt wird. 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 Microsoft.Testing.Platform bezeichnet. In Microsoft.Testing.Platform erfolgt die Protokollierung nur für Diagnosezwecke.

Ähnlich wie --collect, --logger ist ein allgemeiner Erweiterbarkeitspunkt in VSTest für jeden Logger (oder im Kontext von Microsoft.Testing.Platform, jeder Reporter). Jeder Microsoft.Testing.Platform 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 Microsoft.Testing.Platform wird der Befehl zu:

dotnet test --report-trx

--settings

VSTest's --settings wird verwendet, um eine RunSettings-Datei für die Testausführung anzugeben. RunSettings wird von der Zentralen Microsoft.Testing.Platform 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 Microsoft.Testing.Platform 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 Microsoft.Testing.Platform aktivieren.

Visual Studio

Visual Studio Test Explorer unterstützt Microsoft.Testing.Platform 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 Microsoft.Testing.Platform.

Azure DevOps

Wenn Sie Azure DevOps-Aufgaben verwenden, müssen Sie Ihre Pipeline möglicherweise aktualisieren, um Microsoft.Testing.Platform 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 DotNetCoreCLI-Aufgabe verwenden, ohne sich für die native Microsoft.Testing.Platform-Erfahrung für .NET 10 SDK und höher über eine global.json-Datei zu entscheiden, müssen Sie die Aufgabe so konfigurieren, dass sie korrekt auf das frühere Ergebnisverzeichnis und den angeforderten TRX-Bericht verweist. Beispiel:

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

Verhaltensunterschiede zwischen VSTest und Microsoft.Testing.Platform

Ausführen von Nulltests

Wenn eine Testassembly keine Tests ausgeführt hat, toleriert VSTest dies und wird erfolgreich beendet. Microsoft.Testing.Platform schlägt jedoch mit Exitcode 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 ist die Codepage auf 65001 festgelegt, die UTF8 entspricht), kann das Verhalten zwischen VSTest und Microsoft.Testing.Platform unterschiedlich sein.

• Mit Microsoft.Testing.Platform wird diese Codierung immer beibehalten.
• Wenn VSTest nicht im Isolationsmodus ausgeführt wird (das Standardverhalten von vstest.console), wird diese Codierung beibehalten, ähnlich wie Microsoft.Testing.Platform.
• 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.