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.

Unterstützte Testframeworks

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.

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

  • --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.
  • Zu allen registrierten Befehlszeilenanbietern, z. B. ihre Werte für name, version, description und options.
  • Zu allen registrierten Tools, z. B. ihre Werte für command, name, version, description und zu allen Befehlszeilenanbietern.

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.

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

Weitere Informationen