Freigeben über

Übersicht über Microsoft.Testing.Platform

  • Artikel

Microsoft.Testing.Platform ist eine einfache und portierbare Alternative zu VSTest zum Ausführen von Tests in allen Kontexten, darunter Continuous Integration-Pipelines (CI), Befehlszeilenschnittstelle, Visual Studio-Test-Explorer und VS Code-Test-Explorer. Microsoft.Testing.Platform ist direkt in Ihre Testprojekte eingebettet, und es sind keine anderen Apps wie vstest.console oder dotnet test erforderlich, um Ihre Tests auszuführen.

Microsoft.Testing.Platform ist Open Source. Sie finden Microsoft.Testing.Platform-Code im Microsoft/testfx GitHub-Repository.

Microsoft.Testing.Platform-Säulen

Diese neue Testplattform basiert auf der Erfahrung des .NET Developer Experience Testing-Teams und zielt darauf ab, die Herausforderungen zu beheben, die seit der Veröffentlichung von .NET Core im Jahr 2016 aufgetreten sind. Obwohl es ein hohes Maß an Kompatibilität zwischen .NET Framework und .NET Core/.NET gibt, haben einige wichtige Features wie das Plug-In-System und die neuen möglichen Formfaktoren von .NET-Kompilierungen es komplex gemacht, das neue Laufzeitfeature mit der aktuellen VSTest-Plattformarchitektur zu entwickeln oder vollständig zu unterstützen.

Die wichtigsten Faktoren für die Entwicklung der neuen Testplattform sind im Folgenden aufgeführt:

  • Determinismus: Sicherstellen, dass das Ausführen der gleichen Tests in verschiedenen Kontexten (lokal, CI) dasselbe Ergebnis erzeugt. Die neue Laufzeit basiert nicht auf Spiegelung oder anderen dynamischen .NET-Laufzeitfeatures, um eine Testausführung zu koordinieren.

  • Laufzeittransparenz: Die Testlaufzeit stört den Testframeworkcode nicht, erstellt keine isolierten Kontexte wie AppDomain oder AssemblyLoadContext, und es verwendet keine Spiegelung oder benutzerdefinierte Assemblylöser.

  • Kompilierungszeitregistrierung von Erweiterungen: Erweiterungen, z. B. Testframeworks und In-of-Process-Erweiterungen, werden während der Kompilierungszeit registriert, um die Determinität zu gewährleisten und die Erkennung von Inkonsistenzen zu erleichtern.

  • Nullabhängigkeiten: Der Kern der Plattform ist eine einzelne .NET-Assembly, Microsoft.Testing.Platform.dlldie keine anderen Abhängigkeiten als die unterstützten Laufzeiten aufweist.

  • Hostbar: Die Testlaufzeit kann in jeder .NET-Anwendung gehostet werden. Während eine Konsolenanwendung häufig zum Ausführen von Tests verwendet wird, können Sie eine Testanwendung in jeder Art von .NET-Anwendung erstellen. Auf diese Weise können Sie Tests in speziellen Kontexten ausführen, z. B. Geräte oder Browser, bei denen es einschränkungen gibt.

  • Unterstützen Sie alle .NET-Formfaktoren: Unterstützen Sie aktuelle und zukünftige .NET-Formfaktoren, einschließlich Native AOT.

  • Performant: Finden Sie das richtige Gleichgewicht zwischen Features und Erweiterungspunkten, um zu vermeiden, dass die Laufzeit mit nicht grundlegendem Code aufgebläht wird. Die neue Testplattform dient dazu, einen Testlauf zu "koordinieren", anstatt Implementierungsdetails zur Vorgehensweise bereitzustellen.

  • Erweiterbar genug: Die neue Plattform basiert auf Erweiterbarkeitspunkten, um eine maximale Anpassung der Laufzeitausführung zu ermöglichen. Sie können den Testprozesshost konfigurieren, den Testprozess beobachten und Informationen aus dem Testframework innerhalb des Testhostprozesses nutzen.

  • Bereitstellung eines einzelnen Moduls: Das Hostierbarkeitsfeature ermöglicht ein einzelnes Modulbereitstellungsmodell, bei dem ein einziges Kompilierungsergebnis verwendet werden kann, um alle Erweiterbarkeitspunkte zu unterstützen, sowohl out-of-process als auch in-process, ohne dass verschiedene ausführbare Module ausgeliefert werden müssen.

Unterstützte Testframeworks

  • MSTest. In MSTest erfolgt die Unterstützung von Microsoft.Testing.Platform über MSTest Runner.
  • NUnit. In NUnit erfolgt die Unterstützung von Microsoft.Testing.Platform über NUnit-Runner.
  • xUnit.net: In xUnit.net erfolgt die Unterstützung von Microsoft.Testing.Platform über xUnit.net-Runner.
  • TUnit: vollständig konstruiert auf der Grundlage von Microsoft.Testing.Platform, , weitere Informationen finden Sie in der TUnit documentation

Ausführen und Debuggen von Tests

Microsoft.Testing.Platform--Testprojekte werden als ausführbare Dateien erstellt, die direkt ausgeführt (oder debuggt) werden können. Es gibt keine zusätzliche Testausführungskonsole und keinen zusätzlichen Befehl. Die App wird mit einem Nonzero-Exitcode beendet, wenn ein Fehler auftritt, wie bei den meisten ausführbaren Dateien. Weitere Informationen zu den bekannten Exitcodes finden Sie unter Microsoft.Testing.Platform-Exitcodes.

Wichtig

Standardmäßig sammelt Microsoft.Testing.Platform Telemetrie. Weitere Informationen und Optionen zum Deaktivieren finden Sie unter Microsoft.Testing.Platform-Telemetrie.

Das Veröffentlichen des Testprojekts mithilfe von dotnet publish und das direkte Ausführen der App ist eine weitere Möglichkeit, Ihre Tests auszuführen. Führen Sie z. B. ./Contoso.MyTests.exe aus. In einigen Szenarien ist es auch praktikabel, dotnet build zur Erstellung der ausführbaren Datei zu verwenden, es kann jedoch auch Grenzfälle geben, z. B. Native AOT.

Verwenden Sie dotnet run

Der dotnet run-Befehl kann zum Erstellen und Ausführen des Testprojekts verwendet werden. Dies ist die einfachste, obwohl manchmal langsamste Möglichkeit, Ihre Tests auszuführen. Die Verwendung von dotnet run ist praktisch, wenn Sie Tests lokal bearbeiten und ausführen, da sichergestellt wird, dass das Testprojekt bei Bedarf neu erstellt wird. dotnet run sucht das Projekt automatisch im aktuellen Ordner.

dotnet run --project Contoso.MyTests

Weitere Informationen zu dotnet run finden Sie unter Dotnet-Ausführung.

Verwenden Sie dotnet exec

Der dotnet exec- oder dotnet-Befehl wird verwendet, um ein bereits erstelltes Testprojekt auszuführen (oder zu nutzen). Dies ist eine Alternative zum direkten Ausführen der Anwendung. dotnet exec erfordert einen Pfad zur integrierten Testprojekt-DLL.

dotnet exec Contoso.MyTests.dll

oder

dotnet Contoso.MyTests.dll

Hinweis

Wenn Sie den Pfad zur ausführbaren Datei des Testprojekts (*.exe) angeben, tritt ein Fehler auf:

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

Weitere Informationen zu dotnet exec finden Sie unter dotnet exec.

Verwenden Sie dotnet test

Microsoft.Testing.Platform bietet eine Kompatibilitätsschicht für vstest.console.exe und dotnet test und stellt so sicher, dass Sie Ihre Tests wie zuvor ausführen können, während gleichzeitig ein neues Ausführungsszenario aktiviert wird.

dotnet test Contoso.MyTests.dll

Optionen

In der nachfolgenden Liste werden nur die Plattformoptionen beschrieben. Um die spezifischen Optionen anzuzeigen, die von jeder Erweiterung bereitgestellt werden, verweisen Sie entweder auf die Dokumentationsseite der Erweiterung, oder verwenden Sie die Option --help.

  • @

    Gibt den Namen der Antwortdatei an. Der Name der Antwortdatei muss sofort dem @-Zeichen ohne Leerzeichen zwischen dem @-Zeichen und dem Antwortdateinamen folgen.

    Optionen in einer Antwortdatei werden so interpretiert, als wären sie an dieser Stelle in der Befehlszeile vorhanden. Jedes Argument in einer Antwortdatei muss mit der gleichen Zeile beginnen und enden. Sie können das umgekehrte Schrägstrichzeichen () nicht verwenden, um Linien zu verketten. Die Verwendung einer Antwortdatei hilft bei sehr langen Befehlen, die die Terminalgrenzwerte überschreiten können. Sie können eine Antwortdatei mit Inline-Befehlszeilenargumenten kombinieren. Zum Beispiel:

    ./TestExecutable.exe @"filter.rsp" --timeout 10s

    wobei filter.rsp den folgenden Inhalt haben kann:

    --filter "A very long filter"

    Alternativ kann eine einzelne RSP-Datei verwendet werden, um sowohl Timeout als auch Filter wie folgt anzugeben:

    ./TestExecutable.exe @"arguments.rsp"

    --filter "A very long filter"
--timeout 10s

  • --config-file

    Gibt eine testconfig.json Datei an.

  • --diagnostic

    Aktiviert die Diagnoseprotokollierung. Die Standardprotokollebene ist Trace. Die Datei wird im Ausgabeverzeichnis mit dem folgenden Namensformat geschrieben: log_[MMddHHssfff].diag.

  • --diagnostic-filelogger-synchronouswrite

    Zwingt die integrierte Dateiprotokollierung, Protokolle synchron zu schreiben. Nützlich für Szenarien, in denen keine Protokolleinträge verloren gehen sollen (bei Prozessabsturz). Dadurch wird die Testausführung verlangsamt.

  • --diagnostic-output-directory

    Das Ausgabeverzeichnis der Diagnoseprotokollierung. Wird es nicht angegeben, wird die Datei im Standardverzeichnis TestResults generiert.

  • --diagnostic-output-fileprefix

    Das Präfix für den Namen der Protokolldatei. Wird standardmäßig auf "log_" festgelegt.

  • --diagnostic-verbosity

    Definiert den Ausführlichkeitsgrad, wenn die Option --diagnostic verwendet wird. Verfügbare Werte sind Trace, Debug, Information, Warning, Error oder Critical.

  • --exit-on-process-exit

    Beenden Sie den Testprozess, wenn ein abhängiger Prozess beendet wird. PID muss angegeben werden.

  • --help

    Gibt eine Beschreibung zur Verwendung des Befehls aus.

  • -ignore-exit-code

    Ermöglicht, dass einige Exitcodes ungleich null ignoriert und stattdessen als 0 zurückgegeben werden. Weitere Informationen finden Sie im Abschnitt Ignorieren spezifischer Exitcodes.

  • --info

    Zeigt erweiterte Informationen zur .NET-Testanwendung an, z. B.:

    • Zur Plattform.
    • Zur Umgebung.
    • Jeder registrierte Kommandozeilenanbieter, wie z. B. name, version, description und options.
    • Jedes registrierte Tool, wie z. B. seine command, name, version, description und alle Kommandozeilen-Anbieter.

    Dieses Feature wird verwendet, um Erweiterungen zu verstehen, die dieselbe Befehlszeilenoption registrieren, oder um die Änderungen bei den verfügbaren Optionen zwischen mehreren Versionen einer Erweiterung (oder der Plattform) zu ermitteln.

  • --list-tests

    Auflisten verfügbarer Tests. Tests werden nicht ausgeführt.

  • --maximum-failed-tests

    Gibt die maximale Anzahl von Testfehlern an, bei deren Erreichen der Testlauf abgebrochen wird. Zur Unterstützung dieses Schalters müssen die Autoren des Frameworks die Funktionalität IGracefulStopTestExecutionCapability implementieren. Der Exit-Code bei Erreichen dieser Anzahl von Testfehlern ist 13. Weitere Informationen finden Sie unter Microsoft.Testing.Platform Exit-Codes.

    Hinweis

    Dieses Feature ist ab Version 1.5 in Microsoft.Testing.Platform verfügbar.

  • --minimum-expected-tests

    Gibt die Mindestanzahl der auszuführenden Tests an. Standardmäßig wird davon ausgegangen, dass mindestens ein Test ausgeführt wird.

  • --results-directory

    Das Verzeichnis, in dem die Testergebnisse gespeichert werden. Wenn das Verzeichnis noch nicht vorhanden ist, wird es erstellt. Der Standardwert ist TestResults im Verzeichnis, das die Testanwendung enthält.

  • --timeout

    Eine globale Zeitüberschreitung für die Testausführung. Nimmt ein Argument als Zeichenfolge im Format <value>[h|m|s] an, wobei <value> ein Float ist.

MSBuild-Integration

The NuGet package Microsoft.Testing.Platform.MSBuild bietet verschiedene Integrationen für Microsoft.Testing.Platform mit MSBuild:

  • Unterstützung für dotnet test Weitere Informationen finden Sie unter Integration von „dotnet test”.
  • Unterstützung für ProjectCapability erforderlich von Visual Studio und Visual Studio Code Test-Explorer.
  • Automatische Generierung des Einstiegspunkts (Main-Methode).
  • Automatische Generierung der Konfigurationsdatei.

Hinweis

Diese Integration funktioniert transitiv (ein Projekt, das auf ein anderes Projekt verweist, das auf dieses Paket verweist, verhält sich so, als ob es auf das Paket verweist) und kann über die IsTestingPlatformApplication-MSBuild-Eigenschaft deaktiviert werden.

Siehe auch