dotnet test with Microsoft. Testing.Platform (MTP)

Dieser Artikel bezieht sich auf: ✔️ .NET 10 SDK und höhere Versionen

Name

dotnet test - .NET Testtreiber, der zum Ausführen von Komponententests mit MTP verwendet wird.

Zusammenfassung

dotnet test
    [<PROJECT_OR_TRAVERSAL_PATH>]
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>]
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [--config-file <CONFIG_FILE>]
    [--results-directory <RESULTS_DIRECTORY>]
    [--results-directory-layout <flat|per-module>]
    [--diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>]
    [--minimum-expected-tests <NUMBER>]
    [--maximum-failed-tests <NUMBER>]
    [--timeout <DURATION>]
    [-e|--environment <NAME="VALUE">]
    [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--use-current-runtime|--ucr]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-dependencies]
    [--no-restore]
    [--nologo|--no-logo|--no-banner]
    [--no-ansi]
    [--no-progress]
    [--no-artifact-post-processing]
    [--output <VERBOSITY_LEVEL>]
    [--show-test-results <OUTCOME>]
    [--list-tests [text|json]]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [--device <DEVICE_ID>]
    [--list-devices]
    [--collect-test-map]
    [--affected-tests]
    [<args>...]

dotnet test -h|--help

Description

Mit MTP dotnet test arbeiten Sie schneller als mit VSTest. Die testbezogenen Argumente sind nicht mehr fest, da sie an die registrierten Erweiterungen im Test project(n) gebunden sind. Darüber hinaus unterstützt MTP beim Ausführen von Tests einen Globbingfilter. Weitere Informationen finden Sie unter MTP.

Important

Erweiterungsspezifische Optionen sind nicht in MTP integriert. Jede Zieltestanwendung muss die Erweiterung registrieren, die eine Option bereitstellt. Fügen Sie das NuGet-Paket der Erweiterung direkt hinzu, oder verwenden Sie eine Test-SDK-Konfiguration oder ein Profil, das das Paket enthält. Andernfalls schlägt die Testausführung mit dem Exitcode 5 fehl, da die Option nicht erkannt wird. Führen Sie diese Option dotnet test --help aus, um die optionen anzuzeigen, die für die ausgewählten Testanwendungen verfügbar sind, und unter Erweiterungsoptionen nach Szenario , um das Paket für eine Option zu finden.

Warnung

Bei der Verwendung global.jsonvon MTP wird erwartet, dotnet test dass alle Testprojekte MTP verwenden. Es ist ein Fehler, wenn eines der Testprojekte VSTest verwendet.

Versionsanforderungen

Der MTP-Modus dotnet test erfordert das .NET 10 SDK und MTP 1.7 oder höher. Optionen, die hinzugefügt wurden, nachdem .NET 10 individuelle SDK-Versionsanforderungen in den folgenden Abschnitten aufweisen. Einige Optionen erfordern auch ein neueres MTP-Paket, da das SDK die vollständige Ausführung koordiniert, während jede Testanwendung die entsprechende Funktion implementiert.

Implizite Wiederherstellung

Sie müssen dotnet restore nicht ausführen, da der Befehl implizit von allen Befehlen ausgeführt wird, die eine Wiederherstellung erfordern. Zu diesen zählen z. B. dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish und dotnet pack. Verwenden Sie die Option --no-restore, um die implizite Wiederherstellung zu deaktivieren.

Der Befehl dotnet restore ist in bestimmten Szenarien weiterhin nützlich, in denen die explizite Wiederherstellung sinnvoll ist, z. B. kontinierende Integrationsbuilds in Azure DevOps Services oder in Buildsystemen, die explizit steuern müssen, wann die Wiederherstellung eintritt.

Informationen zum Verwalten von NuGet-Feeds finden Sie in der dotnet restoreDokumentation.

Options

Hinweis

Sie können jeweils nur eine der folgenden Optionen verwenden: --project, --solution oder --test-modules. Diese Optionen können nicht kombiniert werden. Darüber hinaus können Sie bei Verwendung --test-modulesnicht angeben--arch, , , --configuration, --device, --framework, --list-devices, --os, , oder --runtime--use-current-runtime. Diese Optionen erfordern eine Projektauswertung oder sind für ein bereits integriertes Modul nicht relevant.

  • PROJECT_OR_TRAVERSAL_PATH

    Gibt ein Projekt oder ein auszuführenes Traversalprojekt an. Ab .NET 11 Preview 7 dotnet test werden Microsoft.Build.Traversal Projekte unterstützt, zdirs.proj. B. und rekursiv ihre referenzierten Testprojekte ausgeführt.

    Ab .NET 12 Preview 1 kann das Argument auch eine C#-dateibasierte MTP-Test-App identifizieren. Dateibasierte Test-Apps werden nicht unterstützt --device.

  • --project <PROJECT_PATH>

    Gibt den Pfad der auszuführenden project Datei an (Ordnername oder vollständiger Pfad). Wenn nicht angegeben, wird standardmäßig das aktuelle Verzeichnis gewählt.

  • --solution <SOLUTION_PATH>

    Gibt den Pfad der auszuführenden Lösungsdatei an (Ordnername oder vollständiger Pfad). Wenn nicht angegeben, wird standardmäßig das aktuelle Verzeichnis gewählt.

  • --test-modules <EXPRESSION>

    Filtert Testmodule mithilfe von Datei-Globbing. Nur Tests, die zu diesen Testmodulen gehören, werden ausgeführt. Ab .NET 11 Preview 6 wird ein Muster vorangestellt, mit ! dem übereinstimmende Module ausgeschlossen werden sollen. Trennen Sie mehrere Muster durch Semikolons; Leerzeichen um jedes Muster werden ignoriert.

  • --root-directory <ROOT_PATH>

    Gibt das Stammverzeichnis der Option --test-modules an. Sie kann nur mit der Option --test-modules verwendet werden.

  • --max-parallel-test-modules <NUMBER>

    Gibt die maximale Anzahl von Testmodulen an, die parallel ausgeführt werden können. Der Standardwert lautet Environment.ProcessorCount.

  • --config-file <CONFIG_FILE>

    Gibt die konfigurationsdatei an, die für die Testausführung verwendet werden soll. Wenn ein relativer Pfad bereitgestellt wird, wird er basierend auf dem aktuellen Verzeichnis in einen absoluten Pfad konvertiert. Weitere Informationen zu den Konfigurationsdateieinstellungen finden Sie untertestconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Gibt das Verzeichnis an, in dem Testergebnisse gespeichert werden. Wenn das Verzeichnis nicht vorhanden ist, wird es erstellt. Wenn ein relativer Pfad bereitgestellt wird, wird er basierend auf dem aktuellen Verzeichnis in einen absoluten Pfad konvertiert.

  • --results-directory-layout <flat|per-module>

    Gibt an, wie eine Mehrmodulausführung Dateien unter dem Ergebnisverzeichnis organisiert. Der Standardwert , flatschreibt alle Ergebnisse in dasselbe Verzeichnis. per-module schreibt die Ergebnisse jedes Moduls in <project>/<target-framework>_<runtime-or-architecture>, wodurch Verhindert wird, dass Berichte mit demselben Dateinamen voneinander überschrieben werden.

    Verfügbar ab .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Gibt das Verzeichnis an, in dem die Diagnoseausgabe gespeichert ist. Wenn das Verzeichnis nicht vorhanden ist, wird es erstellt. Wenn ein relativer Pfad bereitgestellt wird, wird er basierend auf dem aktuellen Verzeichnis in einen absoluten Pfad konvertiert.

  • --minimum-expected-tests <NUMBER>

    Gibt eine positive Mindestanzahl von Tests für die gesamte Ausführung an. Wenn die aggregierte Testanzahl kleiner als das angegebene Minimum ist, schlägt die Testausführung mit Exitcode 9 fehl. Die globale Anzahl enthält übersprungene Tests. Weitere Informationen zu Exitcodes finden Sie unter MTP-Exitcodes.

    Da diese Option vor --angezeigt wird, handelt es sich um eine globale Option (Ganzausführung). Wenn Sie stattdessen ein Minimum für jedes Testmodul benötigen möchten, übergeben Sie die Option danach -- , damit sie an jedes Testmodul weitergeleitet wird. Weitere Informationen finden Sie unter "Gesamte Ausführung" und "Mindestwerte pro Modul".

    Hinweis

    Das globale Minimum erfordert das .NET 10 SDK (10.0.100) oder eine höhere Version.

  • --maximum-failed-tests <NUMBER>

    Beendet die vollständige Ausführung, nachdem sie die angegebene Anzahl von fehlgeschlagenen, fehlerhaften, timedout- oder abgebrochenen Tests erreicht hat. Die Ausführung wird mit Code 13 beendet.

    Verfügbar ab .NET 11 Preview 7 und erfordert MTP 2.4 oder höher.

  • --timeout <DURATION>

    Beendet die vollständige Ausführung nach der angegebenen Dauer, während mindestens eine Testanwendung ausgeführt wird. Geben Sie eine positive Zahl gefolgt von einer Einheit an, z 500ms. B. , , 90s, 10m, 2hoder 1d. Ein Timeout wird mit Code 3 beendet.

    Verfügbar ab .NET 11 Preview 7 und erfordert MTP 2.4 oder höher.

  • -e|--environment <NAME="VALUE">

    Legt eine Umgebungsvariable für den Testprozess fest. Geben Sie die Option mehrmals an, um mehrere Variablen festzulegen. Befehlszeilenwerte überschreiben Werte aus einem Startprofil.

    Verwenden Sie .NET SDK 10.0.110 oder höher, wenn kein Startprofil vorhanden ist oder wenn Sie angeben--no-launch-profile; frühere .NET 10 SDK-Versionen können die Variablen in diesen Fällen ignorieren. Ab .NET 11 Preview 7 fließen die Variablen auch zu funktionsfähigen Build-, Geräteauswahl-, Bereitstellungs- und Ausführungsargumentzielen.

  • -a|--arch <ARCHITECTURE>

    Legt die Zielarchitektur fest. Dies ist eine Kurzsyntax zum Setzen des Runtimebezeichners (RID), wobei der angegebene Wert mit dem Standard-RID kombiniert wird. Auf einem win-x64 Rechner wird beispielsweise durch die Angabe von --arch x86 der RID auf win-x86 gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option -r|--runtime nicht verwenden. Verfügbar seit .NET 6 Preview 7.

  • --artifacts-path <ARTIFACTS_DIR>

    Alle Buildausgabedateien des ausgeführten Befehls werden in Unterordnern unter dem angegebenen Pfad, getrennt durch Das Projekt, verschoben. Weitere Informationen finden Sie unter "Artifacts Output Layout". Diese Option und der bereitgestellte Wert müssen in jedem dotnet Befehl explizit kaskadiert werden, der von der Ausgabe eines anderen dotnet Befehls abhängt, z. B. bei Verwendung dotnet build --no-restore und dotnet publish --no-build. Verfügbar seit .NET 8 SDK.

    Verfügbar für den MTP-Modus ab .NET 11.

  • -c|--configuration <CONFIGURATION>

    Definiert die Buildkonfiguration. Die Standardeinstellung für die meisten Projekte ist Debug, Sie können jedoch die Buildkonfigurationseinstellungen in Ihrer project überschreiben.

  • -f|--framework <FRAMEWORK>

    Der Zielframeworkmoniker (Target Framework Moniker, TFM) des Zielframeworks, für das Tests ausgeführt werden sollen. Das Zielframework muss auch in der datei project angegeben werden.

  • --os <OS>

    Gibt das Zielbetriebssystem an. Dies ist eine Kurzsyntax zum Setzen des Runtimebezeichners (RID), wobei der angegebene Wert mit dem Standard-RID kombiniert wird. Auf einem win-x64 Rechner wird beispielsweise durch die Angabe von --os linux der RID auf linux-x64 gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option -r|--runtime nicht verwenden. Verfügbar seit .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Die Zielruntime, für die Tests ausgeführt werden sollen.

    Kurzform -r ab .NET SDK 7 verfügbar.

    Hinweis

    Das Ausführen von Tests für eine Lösung mit einer globalen RuntimeIdentifier Eigenschaft (explizit oder über --arch, --runtimeoder --osüber ) wird nicht unterstützt. Legen Sie stattdessen RuntimeIdentifier auf einer einzelnen project-Ebene fest.

  • --use-current-runtime|--ucr

    Verwendet die aktuelle Laufzeit während der Wiederherstellung und Erstellung als Ziellaufzeit.

    Verfügbar ab .NET 11 Preview 6. Sie können diese Option nicht mit --test-modules.

  • -v|--verbosity <LEVEL>

    Legt den Ausführlichkeitsgrad für den Befehl fest. Zulässige Werte sind q[uiet], m[inimal], n[ormal], d[etailed] und diag[nostic]. Weitere Informationen finden Sie unter LoggerVerbosity.

  • --no-build

    Gibt an, dass der Test project nicht erstellt wird, bevor er ausgeführt wird. Außerdem wird das --no-restore Flag implizit festgelegt.

  • --no-dependencies

    Überspringt das Erstellen von Projekt-zu-Projekt-Verweisen.

    Verfügbar ab .NET 11 Preview 6.

  • --no-restore

    Gibt an, dass eine implizite Wiederherstellung beim Ausführen des Befehls nicht ausgeführt wird.

  • --nologo|--no-logo|--no-banner

    Unterdrückt die .NET- und MTP-Startbanner. Die -nologo Formulare und /nologo die Umgebungsvariable DOTNET_NOLOGO werden ebenfalls unterstützt.

    Verfügbar im MTP-Modus ab .NET 11 Preview 7.

  • --no-ansi

    Deaktiviert die Ausgabe von ANSI-Escapezeichen auf den Bildschirm.

  • --no-progress

    Deaktiviert den Status der Berichterstellung auf dem Bildschirm.

  • --no-artifact-post-processing

    Deaktiviert die Nachbearbeitung kompatibler Artefakte nach der Ausführung eines Multimoduls. Ab .NET 11 RC 1 und MTP 2.4 können registrierte Artefakt-Postprozessoren kompatible Berichte wie TRX-Ergebnisse kombinieren. Wenn nach der Verarbeitung ein Fehler auftritt, behält das SDK die ursprünglichen Artefakte und den Testausgangscode bei.

  • --output <VERBOSITY_LEVEL>

    Gibt die Ausführlichkeit der Ausgabe für Testergebnisse an. Gültige Werte sind Minimal, Normalund Detailed. Der Standardwert lautet Normal. Minimal erfordert MTP 2.4 Preview.

  • --show-test-results <OUTCOME>

    Wählt Ergebnisblöcke nach Ergebnis aus. Verwenden Sie in der MTP 2.4-Vorschau , verwenden passedSie , failed, , skipped, alloder none. Der failed Wert enthält auch Fehler, Timeouts und Abbrüche.

    Kombinieren, passedund failedskipped mit Kommas, Leerzeichen oder wiederholten --show-test-results Optionen. Kombinieren Sie nicht all oder none mit einem anderen Wert. Diese explizite Option setzt die --output Voreinstellung unabhängig von der Optionsreihenfolge außer Kraft.

  • --list-tests [text|json]

    Listet ermittelte Tests auf, ohne sie auszuführen. Lassen Sie den Wert aus, oder geben Sie text den Wert für die lesbare Ausgabe an. Geben Sie ab .NET 11 Preview 7 ein versionsiertes JSON-Dokument anjson, das Tests nach Assembly, Zielframework und Architektur gruppiert und verfügbare Bezeichner, Quellspeicherorte, Methoden, Parameter und Merkmale enthält.

  • --no-launch-profile

    Versuchen Sie nicht, launchSettings.json zum Konfigurieren der Anwendung zu verwenden. launchSettings.json Standardmäßig wird verwendet, mit dem Umgebungsvariablen und Befehlszeilenargumente auf die ausführbare Testdatei angewendet werden können.

  • --no-launch-profile-arguments

    Verwenden Sie keine Argumente, die im commandLineArgs Startprofil angegeben sind, um die Anwendung auszuführen.

  • --device <DEVICE_ID>

    Wählt ein Gerät, einen Emulator oder einen Simulator für jedes Zielframework in einem Android- oder iOS-Testprojekt aus. Der MTP-Pfad unterstützt auch macOS- und Mac Catalyst-Testprojekte. Wenn die Eingabe interaktiv ist und mehrere Geräte verfügbar sind, können Sie aufgefordert werden, dotnet test ein Gerät auszuwählen.

    Verfügbar ab .NET 11 Preview 6. Verwenden Sie für gezielte Projekte .NET 11 RC 2 oder höher, sodass die Geräteermittlung jedes Zielframework korrekt auswertet. Browser-WebAssembly-Testprojekte werden von dieser Option nicht unterstützt.

  • --list-devices

    Listet verfügbare Geräte für ein Projekt auf, ohne Tests auszuführen. Geben Sie ein Projekt anstelle einer Lösung an.

    Verfügbar ab .NET 11 Preview 7.

  • --collect-test-map und --affected-tests

    Sammeln Sie eine Repositorytestzuordnung, oder führen Sie Tests aus, die von einer Änderung betroffen sind. Für diese experimentellen Optionen ist eine separat verteilte Erweiterung und die DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 Umgebungsvariable erforderlich. Sie können die beiden Optionen nicht kombinieren. Betroffene Testworkflows unterstützen auch keine Gerätetests, parallele Testmodule oder Mindesttestrichtlinien.

    Verfügbar ab .NET 11 RC 1.

  • --property:<NAME>=<VALUE>

    Legt eine oder mehrere MSBuild Eigenschaften fest. Geben Sie mehrere Eigenschaften an, indem Sie die Option wiederholen:

    --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

    Die Kurzform -p kann für --property verwendet werden. Das gleiche gilt für /property:property=value und die kurzform ist /p. Weitere Informationen zu den verfügbaren Argumenten finden Sie in der Dokumentation zu dotnet msbuild.

  • -?|-h|--help

    Gibt eine Beschreibung zur Verwendung des Befehls aus.

  • args

    Gibt zusätzliche Argumente an, die an die Testanwendung(en) übergeben werden sollen. Trennt mehrere Argumente durch Leerzeichen. Weitere Informationen und Beispiele zu den zu übergebenden Funktionen finden Sie unter MTP-Übersicht und MTP-Features.

    Tipp

    Verwenden Sie die TestingPlatformCommandLineArguments MSBuild-Eigenschaft, um zusätzliche Argumente für bestimmte Projekte anzugeben. Diese Eigenschaft ist besonders nützlich, wenn Ihre Lösung Testframeworks (z. B. MSTest und xUnit.net) kombiniert oder wenn nur einige Projekte auf eine bestimmte Erweiterung verweisen. Weitere Informationen finden Sie unter Lösungen mit gemischten Testframeworks oder Erweiterungen.

Hinweis

Um die Ablaufverfolgungsprotokollierung in einer Datei zu aktivieren, verwenden Sie die Umgebungsvariable DOTNET_CLI_TEST_TRACEFILE, um den Pfad zur Ablaufverfolgungsdatei bereitzustellen.

Ab .NET 11 RC 1 verwendet dotnet test -bl eine MSBuild-Sitzung für Multiprojekt-, Multi-Targeted- und Device-Ausführung, sodass das Binärprotokoll den vollständigen Build enthält.

Ausgabe- und Abbruchverhalten

Ab .NET 11 Preview 6 zeigt die interaktive ANSI-Ausgabe Tests an, die derzeit ausgeführt werden, und berichte pro Assemblytest. Die Statusanzeige bleibt deaktiviert, wenn die Ausgabe umgeleitet wird, die ANSI- oder Statusausgabe deaktiviert ist oder die Umgebung nicht interaktiv ist.

Ab .NET 11 Preview 6 stoppt die erste STRG+C die Planung neuer Testanwendungen und fordert eine kooperative Abbruchanforderung an. Drücken Sie erneut STRG+C , um die untergeordneten Prozesse sofort zu beenden. Eine abgebrochene Ausführung wird mit Code 3 beendet.

Für die Livetesthostausgabe ist ein MTP-Host erforderlich, der Protokoll 1.1 oder höher unterstützt. Ältere Hosts behalten die Ausgabeerfassung bei und geben sie für ein fehlerhaftes Modul wieder. Beginnend mit .NET 11 Vorschau 7 werden die erfassten Standardausgaben abgeschnitten, die länger als 40 Zeilen bis zu den ersten 30 und letzten 10 Zeilen sind. Diagnoseprotokolle behalten die vollständige Ausgabe bei.

Bei Ausführung mit mehreren Modulen wird das Nulltestergebnis für die gesamte Ausführung ausgewertet, dotnet test beginnend mit .NET 11 Preview 7. Ein Modul ohne Tests schlägt die Ausführung nicht fehl, wenn ein anderes Modul Tests erfolgreich ausführt, es sei denn, eine explizite Mindesttestrichtlinie erfordert mehr Tests.

Ergebnisse und Artefakte

Wenn das Ausgabelayout für SDK-Artefakte aktiviert ist, platzieren .NET 11 RC 1 und höher standardmäßig MTP-Berichte, Abdeckungsdateien und Diagnosen<ArtifactsPath>/test/<project>/<pivot>. Eine explizite --results-directory oder --results-directory-layout hat Vorrang.

Ab .NET 11 RC 1 und MTP 2.4 können kompatible Erweiterungen Nachbearbeitungsartefakte aus einer Multimodulausführung durchführen. Beispielsweise kann die TRX-Erweiterung einen zusammengeführten Bericht erstellen und gleichzeitig die Berichte pro Modul beibehalten. Informationen zu Erweiterungs- und Berichtsanforderungen finden Sie in den MTP-Testberichten.

Weiterleiten von Argumenten an die Testanwendung

dotnet test leitet jedes Token weiter, das er nicht an die Testanwendung erkennt. Wenn eine erkannte Option zwischen einem unbekannten Optionsnamen und seinem Wert angezeigt wird, kann durch das Entfernen der erkannten Option die Bindung der Linkstoken an Optionen in der Testanwendung geändert werden. Um diese Mehrdeutigkeit zu vermeiden, platzieren Sie Testanwendungsargumente nach einem Literal --:

dotnet test --results-directory TestResults -- --report-trx --report-trx-filename A.trx

Im vorherigen Beispiel ist das Microsoft.Testing.Extensions.TrxReport Paket entweder als direkter Paketverweis oder über eine Test-SDK-Konfiguration erforderlich, die es enthält.

Dasselbe Parserverhalten gilt für dotnet run und dotnet build. Ein ausführliches Beispiel finden Sie unter Weiterleiten von Argumenten an die Anwendung in derdotnet run Referenz.

Mindestwerte für die gesamte Ausführung und pro Modul

For --minimum-expected-tests, the -- separator determines the option's scope:

  • Argumente vorher-- sind global. Der dotnet test Orchestrator interpretiert sie für den gesamten Lauf.
  • Argumente danach-- sind lokal. dotnet test leitet sie an jedes Testmodul weiter, sodass jedes Modul sie unabhängig voneinander anwendet.

Da --minimum-expected-tests in beiden Bereichen verfügbar ist, können Sie für die gesamte Ausführung, für jedes Modul oder beides ein Minimum anfordern:

dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

Der vorstehende Befehl erfordert mindestens 5 Tests für die gesamte Ausführung und mindestens 2 Tests in jedem Testmodul.

Die beiden Bereiche zählen übersprungene Tests unterschiedlich:

Geltungsbereich Zählen übersprungene Tests auf das Minimum?
Global Yes. Die dotnet test aggregierte Summe umfasst übersprungene Tests.
Pro Modul No. MTP schließt übersprungene Tests aus der Anzahl der ausgeführten Tests aus.

Beginnend mit dem .NET 11 SDK wird die Nulltestbewertung für die gesamte Ausführung einmal aus den aggregierten Ergebnissen entschieden. Ein Modul, das keine Tests abgleicht, z. B. aufgrund oder --test-modules global --filter, mit Code 8 (ZeroTests), aber dieser Code wird normalisiert, bevor die Ergebnisse aggregiert werden. Daher schlägt ein einzelnes leeres Modul die gesamte Ausführung nicht fehl, obwohl das Modul seine Exit code: 8 Diagnose in der Ausgabe für die Sichtbarkeit behält.

MTP 4.3.0 und höhere Versionen bieten --zero-tests-policy <allow-skipped|strict>. Mit dem Standardwert allow-skippedkann ein übersprungenes Modul erfolgreich ausgeführt werden. Der strict Wert behandelt übersprungene Tests als nicht ausgeführt, sodass ein übersprungenes Modul mit Code 8 beendet wird. Übergeben Sie die Option nach -- der Weiterleitung an jedes Testmodul:

dotnet test -- --zero-tests-policy strict

Wenn Sie kein globales Minimum festlegen, bestimmt das .NET 11 SDK die vollständige Nulltestbewertung separat. Eine übersprungene ganze Ausführung wird unabhängig vom Wert pro Modul --zero-tests-policy mit Code 8 beendet.

Wenn Sie angeben --minimum-expected-tests und das Minimum nicht erfüllt ist, schlägt die Ausführung mit Exitcode 9 (MinimumExpectedTestsPolicyViolation) fehl. Dieser Code unterscheidet sich von 8, sodass ein strengeres globales oder pro Modul minimum nicht mit einem leeren Modul verwechselt wird. Damit pro Modul mindestens Code 9 zurückgegeben werden kann, wenn das Modul Nulltests ausführt, muss das Testmodul MTP 4.4.0 oder eine höhere Version verwenden.

Hinweis

--minimum-expected-tests 0 ist ungültig. Verwenden Sie die Verwendung --ignore-exit-code 8, um den Beendigungscode für Nulltests zu unterdrücken.

Beginnend mit .NET 11 Preview 6, --tl, --terminalloggerund --tlp werden anstelle der Testanwendung an MSBuild weitergeleitet. Ab .NET 12 Preview 1 werden die erkannten -mt formulare -multiThreaded auch an MSBuild weitergeleitet. Wenn Sie eine Anwendungsoption mit einem dieser Namen übergeben möchten, platzieren Sie sie nach --.

Übergeben Sie Ausführungsmodusoptionen wie --help z. B. direkt --list-tests an dotnet test. Ab .NET 11 Preview 6 überprüft das SDK den mit der Testanwendung ausgehandelten Ausführungsmodus. Wenn ein Startprofil TestingPlatformCommandLineArguments oder eine dieser Optionen injiziert wird, stimmen der angeforderte SDK-Vorgang und der Anwendungsvorgang nicht überein, und die Ausführung schlägt mit einer Diagnose fehl.

Examples

  • Führen Sie die Tests im project oder der Lösung im aktuellen Verzeichnis aus:

    dotnet test

  • Führen Sie die Tests im TestProject project aus:

    dotnet test --project ./TestProject/TestProject.csproj

  • Führen Sie die Tests in der TestProjects Lösung aus:

    dotnet test --solution ./TestProjects/TestProjects.sln

  • Führen Sie die Tests mit der Assembly TestProject.dll aus:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"

  • Führen Sie die Tests mit TestProject.dll Assembly mit dem Stammverzeichnis aus:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"

  • Führen Sie alle Testprojekte aus, auf die von einem Traversalprojekt verwiesen wird, mit .NET 11 Preview 7 oder höher:

    dotnet test dirs.proj

  • Listen Sie Tests als JSON mit .NET 11 Preview 7 oder höher auf:

    dotnet test --list-tests json

  • Führen Sie eine C#-dateibasierte MTP-Test-App mit .NET 12 Preview 1 oder höher aus:

    dotnet test App.Tests.cs

  • Führen Sie die Tests im aktuellen Verzeichnis mit der Microsoft Codeabdeckungserweiterung aus. Die Testanwendung muss entweder direkt oder über eine Test-SDK-Konfiguration verweisen Microsoft.Testing.Extensions.CodeCoverage, die sie enthält:

    dotnet test --coverage

  • Führen Sie die Tests aus, und speichern Sie die Ergebnisse in einem bestimmten Verzeichnis:

    dotnet test --results-directory ./TestResults

  • Führen Sie die Tests mit Diagnoseausgabe in einem bestimmten Verzeichnis aus:

    dotnet test --diagnostic-output-directory ./Diagnostics

  • Führen Sie die Tests aus, die sicherstellen, dass mindestens 10 Tests ausgeführt werden:

    dotnet test --minimum-expected-tests 10

  • Sie benötigen mindestens 5 Tests für die gesamte Ausführung und mindestens 2 Tests in jedem Testmodul:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2

  • Führen Sie die Tests im TestProject project aus, und stellen Sie das Argument -bl (Binärprotokoll) für msbuild bereit:

    dotnet test --project ./TestProject/TestProject.csproj -bl

  • Führen Sie die Tests im TestProject project aus, und legen Sie die MSBuild-Eigenschaft DefineConstants auf DEV fest:

    dotnet test --project ./TestProject/TestProject.csproj -p:DefineConstants="DEV"

Siehe auch

  • Last updated on