Freigeben über

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

Zusammenfassung

dotnet test
    [--project <PROJECT_PATH>]
    [--solution <SOLUTION_PATH>]
    [--test-modules <EXPRESSION>] 
    [--root-directory <ROOT_PATH>]
    [--max-parallel-test-modules <NUMBER>]
    [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>]
    [--os <OS>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [-v|--verbosity <LEVEL>]
    [--no-build]
    [--no-restore]
    [--no-ansi]
    [--no-progress]
    [--output <VERBOSITY_LEVEL>]
    [--no-launch-profile]
    [--no-launch-profile-arguments]
    [<args>...]

dotnet test -h|--help

Description

Mit der Microsoft-Testplattform funktioniert dotnet test schneller als mit VSTest. Die testbezogenen Argumente sind nicht mehr fest, da sie an die registrierten Erweiterungen im Testprojekt(n) gebunden sind. Darüber hinaus unterstützt MTP beim Ausführen von Tests einen Globbingfilter. Weitere Informationen finden Sie unter "Microsoft.Testing.Platform".

Warnung

Wenn Microsoft.Testing.Platform über global.jsonaktiviert ist, erwartet dotnet test, dass alle Testprojekte Microsoft.Testing.Platform verwenden. Es ist ein Fehler, wenn eines der Testprojekte VSTest verwendet.

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.

In bestimmten Fällen eignet sich der dotnet restore-Befehl dennoch. Dies ist etwa bei Szenarios der Fall, in denen die explizite Wiederherstellung sinnvoll ist. Beispiele hierfür sind Continuous Integration-Builds in Azure DevOps Services oder Buildsysteme, die den Zeitpunkt für die Wiederherstellung explizit steuern müssen.

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, , --solutionoder --test-modules. Diese Optionen können nicht kombiniert werden. Darüber hinaus können Sie bei Verwendung von --test-modulesnicht --arch, --configuration, --framework, --osoder --runtimeangeben. Diese Optionen sind für ein bereits integriertes Modul nicht relevant.

  • --project <PROJECT_PATH>

    Gibt den Pfad der auszuführenden Projektdatei 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 in .NET. Es werden nur Tests ausgeführt, die zu diesen Testmodulen gehören. Weitere Informationen und Beispiele zur Verwendung von Datei-Globbing in .NET finden Sie unter Datei-Globbing-.

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

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

  • -c|--configuration <CONFIGURATION>

    Definiert die Buildkonfiguration. Die Standardeinstellung für die meisten Projekte ist Debug, Aber Sie können die Buildkonfigurationseinstellungen in Ihrem Projekt außer Kraft setzen.

  • -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 Projektdatei 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 RuntimeIdentifier stattdessen auf einer einzelnen Projektebene fest.

  • -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 das Testprojekt vor der Ausführung nicht erstellt wird. Außerdem wird das --no-restore Flag implizit festgelegt.

  • --no-restore

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

  • --no-ansi

    Deaktiviert die Ausgabe von ANSI-Escapezeichen auf den Bildschirm.

  • --no-progress

    Deaktiviert den Status der Berichterstellung auf dem Bildschirm.

  • --output <VERBOSITY_LEVEL>

    Gibt die Ausführlichkeit der Ausgabe beim Melden von Tests an. Gültige Werte sind Normal und Detailed. Der Standardwert lautet Normal.

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

  • --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 zum Übergeben finden Sie in Microsoft.Testing.Platform -Übersicht und Microsoft.Testing.Platform-Erweiterungen.

    Tipp

    Verwenden Sie die TestingPlatformCommandLineArguments MSBuild-Eigenschaft, um zusätzliche Argumente für bestimmte Projekte anzugeben.

Hinweis

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

Examples

  • Führen Sie die Tests im Projekt oder der Projektmappe im aktuellen Verzeichnis aus:

    dotnet test

  • Führen Sie die Tests im Projekt TestProject durch:

    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 die Tests im aktuellen Verzeichnis mit Codeabdeckung aus:

    dotnet test --coverage

  • Führen Sie die Tests im Projekt TestProject 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 Projekt TestProject 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