Microsoft.Testing.Platform ist eine einfache und tragbare Alternative zu VSTest- für die Ausführung von Tests in allen Kontexten, einschließlich fortlaufender Integrationspipelinen, CLI, 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.
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 Laufzeitumgebung basiert nicht auf Reflexion oder anderen dynamischen Funktionen der .NET-Laufzeitumgebung, um den Ablauf eines Tests 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 Dokumentation zu TUnit.
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, der für die meisten ausführbaren Dateien typisch ist. Weitere Informationen zu den bekannten Exitcodes finden Sie unter Microsoft.Testing.Platform-Exitcodes.
Tipp
Mithilfe der Befehlszeilenoption --ignore-exit-code können Sie einen bestimmten Exitcode ignorieren.
Sie können auch Befehlszeilenoptionen festlegen, die für ein bestimmtes Testprojekt in der Projektdatei mit der TestingPlatformCommandLineArguments MSBuild-Eigenschaft gelten. Ein gängiger Anwendungsfall ist für Testprojekte mit ignorierten Tests, die normalerweise mit Exitcode 8 beendet werden (die Testsitzung hat null Tests ausgeführt). In diesem Szenario können Sie folgendes unter einer PropertyGroup in Ihrer Projektdatei hinzufügen:
<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
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.
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 wird das Projekt auch automatisch im aktuellen Ordner finden.
dotnet run --project Contoso.MyTests
Weitere Informationen zu dotnet run finden Sie unter dotnet run.
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.
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
Die Microsoft.Testing.Platform-Tests können in Visual Studio ausgeführt (und debuggt) werden. Sie sind in Test-Explorer integriert und können auch direkt als Startprojekt ausgeführt werden.
Ausführen der App mit Visual Studio
Microsoft.Testing.Platform-Testprojekte werden als ausführbare Dateien erstellt und können direkt ausgeführt werden. Dadurch werden alle Tests in der angegebenen ausführbaren Datei ausgeführt, es sei denn, ein Filter wird angewendet.
- Navigieren Sie zum Testprojekt, das Sie im Projektmappen-Explorer ausführen möchten, wählen Sie es mit der rechten Maustaste aus, und wählen Sie Als Startprojekt festlegen aus.
- Wählen Sie Debuggen>Start ohne Debugging aus (oder verwenden Sie STRG+F5), um das ausgewählte Testprojekt auszuführen.
Das Konsolenfenster zeigt die Ausführung und Zusammenfassung Ihres Testlaufs an.
Debuggen der App direkt in Visual Studio
Das Microsoft.Testing.Platform-Testprojekt kann direkt debuggt werden. So debuggen Sie alle Tests in der angegebenen ausführbaren Datei, es sei denn, ein Filter wird angewendet:
- Navigieren Sie zum Testprojekt, das Sie im Projektmappen-Explorer ausführen möchten, wählen Sie es mit der rechten Maustaste aus, und wählen Sie Als Startprojekt festlegen aus.
- Legen Sie den Breakpoint in dem Test fest, den Sie debuggen möchten.
- Wechseln Sie zu Debuggen>Debuggen starten (oder drücken Sie F5), um das ausgewählte Testprojekt zu debuggen.
Alle Tests werden ausgeführt, bis der Test mit dem Breakpoint erreicht wird. Führen Sie den Test schrittweise aus, um ihn zu debuggen. Nachdem Sie mit dem Debuggen der App fertig sind, werden alle verbleibenden Tests fortgesetzt, es sei denn, Sie beenden sie.
Verwenden des Test-Explorers
Um einen Test auszuführen, navigieren Sie zum Test-Explorer, wählen Sie den Test (oder die Tests) aus, der ausgeführt werden soll. Klicken Sie mit der rechten Maustaste darauf, und wählen Sie Ausführen aus. Ähnlich wie beim Debuggen eines Tests wählen Sie den Test (oder die Tests) im Test-Explorer aus, und klicken mit der rechten Maustaste auf Debuggen.
Hinweis
Die automatische Aktualisierung von Tests, ohne das Projekt zu erstellen, ist nicht verfügbar.
Mit der C#-Erweiterung und dem C# Dev Kit können Sie Tests in Visual Studio-Code debuggen/ausführen sowie die Integration mit dem Test-Explorer von Visual Studio Code hinzufügen.
Ausführen der App mit Visual Studio Code
Microsoft.Testing.Platform-Testprojekte werden als ausführbare Dateien erstellt und können direkt ausgeführt werden. Dadurch werden alle Tests in der angegebenen ausführbaren Datei ausgeführt, es sei denn, ein Filter wird angewendet.
- Navigieren Sie zu einer Testdatei, für die Sie Tests ausführen möchten.
- Verwenden Sie STRG+F5, um das ausgewählte Testprojekt auszuführen. Wenn Sie über mehrere Projekte verfügen, werden Sie aufgefordert, das auszuführende Projekt auszuwählen.
Das Konsolenfenster wird mit der Ausführung und Zusammenfassung der Testausführung angezeigt.
Debuggen der App direkt in Visual Studio Code
Microsoft.Testing.Platform-Testprojekte werden als ausführbare Dateien erstellt und können direkt ausgeführt werden. Dadurch werden alle Tests in der angegebenen ausführbaren Datei ausgeführt, es sei denn, ein Filter wird angewendet.
- Navigieren Sie zu einer Testdatei, für die Sie Tests ausführen möchten.
- Verwenden Sie F5, um das ausgewählte Testprojekt zu debuggen. Wenn Sie über mehrere Projekte verfügen, werden Sie aufgefordert, das auszuführende Projekt auszuwählen.
Tipp
Es gibt mehrere andere Möglichkeiten, ein Dotnet-Projekt mit C# DevKit auszuführen, z. B. das Ausführen über den Projektmappen-Explorer oder das Erstellen entsprechender Startkonfigurationen. Diese werden in der Visual Studio Code-Dokumentation angegeben.
Wenn das Projekt ausgeführt wird, erscheint das Ausgabefeld mit der Ausführung des Tests und der Zusammenfassung.
Verwenden des Test-Explorers
Um einen Test auszuführen, navigieren Sie zum Test-Explorer, wählen Sie den Test (oder die Tests) aus, der ausgeführt werden soll. Klicken Sie mit der rechten Maustaste darauf, und wählen Sie Ausführen aus. Ähnlich wie beim Debuggen eines Tests wählen Sie den Test (oder die Tests) im Test-Explorer aus, und klicken mit der rechten Maustaste auf Debuggen.
Hinweis
Die automatische Aktualisierung von Tests, ohne das Projekt zu erstellen, ist nicht verfügbar.
Es gibt keine spezielle Pipelineaufgabe oder zusätzliche Tools zum Ausführen von Testing.Platform-Tests. Es gibt auch keine anderen Tools, die zum Ausführen mehrerer Testprojekte über einen einzigen Befehl erforderlich sind.
Um ein Testprojekt in CI auszuführen, fügen Sie einen Schritt für jede ausführbare Testdatei hinzu, die Sie ausführen möchten, z. B. diese in Azure DevOps:
- task: CmdLine@2
displayName: "Run Contoso.MyTests"
inputs:
script: '.\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'
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 unmittelbar auf das @-Zeichen folgen, und es darf kein Leerzeichen zwischen dem @-Zeichen und dem Namen der Antwortdatei vorhanden sein.
Optionen in einer Antwortdatei werden so interpretiert, als ob sie an dieser Stelle in der Befehlszeile vorhanden wären. Jedes Argument in einer Antwortdatei muss mit der gleichen Zeile beginnen und enden. Sie können einen umgekehrten Schrägstrich (\) nicht zum Verketten von Zeilen verwenden. Die Verwendung einer Antwortdatei ist bei sehr langen Befehlen hilfreich, die die Terminalgrenzen überschreiten können. Sie können eine Antwortdatei mit Inline-Befehlszeilenargumenten kombinieren. Beispiel:
./TestExecutable.exe @"filter.rsp" --timeout 10s
wobei filter.rsp den folgenden Inhalt haben kann:
--filter "A very long filter"
Alternativ können Sie mit einer einzelnen RSP-Datei wie folgt sowohl Timeout als auch Filter angeben:
./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 den integrierten Dateilogger, 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. Die PID muss angegeben werden.
--help
Gibt eine Beschreibung zur Verwendung des Befehls aus.
-ignore-exit-code
Erlaubt, dass einige Nicht-Null-Exitcodes ignoriert werden 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.:
- Die 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 angegebene Verzeichnis noch nicht existiert, 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.
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 für die Test-Explorer Visual Studio und Visual Studio Code.
- 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.
