Udostępnij przez


dotnet test with Microsoft.Testing.Platform (MTP) (dotnet test with Microsoft.Testing.Platform (MTP)

Ten artykuł dotyczy: ✔️ zestawu .NET 10 SDK i nowszych wersji

Name

dotnet test — Sterownik testowy platformy .NET używany do wykonywania testów jednostkowych za pomocą biblioteki Microsoft.Testing.Platform.

Streszczenie

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

W przypadku platformy Microsoft Testing Platform dotnet test działa szybciej niż w programie VSTest. Argumenty związane z testem nie są już stałe, ponieważ są one powiązane z zarejestrowanymi rozszerzeniami w projektach testowych. Ponadto protokół MTP obsługuje filtr globbingu podczas uruchamiania testów. Aby uzyskać więcej informacji, zobacz Microsoft.Testing.Platform.

Ostrzeżenie

Gdy platforma Microsoft.Testing.Platform zostanie wybrana za pośrednictwem global.json, dotnet test oczekuje, że wszystkie projekty testowe będą korzystać z platformy Microsoft.Testing.Platform. Jest to błąd, jeśli którykolwiek z projektów testowych używa narzędzia VSTest.

Niejawne przywracanie

Nie musisz uruchamiać dotnet restore, ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishi dotnet pack. Aby wyłączyć niejawne przywracanie, użyj opcji --no-restore.

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie pakietów ma sens, takie jak w budowaniu ciągłej integracji w środowisku Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy następuje przywracanie pakietów.

Aby uzyskać informacje na temat zarządzania kanałami informacyjnymi NuGet, zobacz dokumentację dotnet restore.

Opcje

Uwaga / Notatka

Jednocześnie można użyć tylko jednej z następujących opcji: --project, --solutionlub --test-modules. Tych opcji nie można połączyć. Ponadto w przypadku korzystania z --test-modulesnie można określić --arch, --configuration, --framework, --osani --runtime. Te opcje nie są istotne dla już utworzonego modułu.

  • --project <PROJECT_PATH>

    Określa ścieżkę pliku projektu do uruchomienia (nazwa folderu lub pełna ścieżka). Jeśli nie zostanie określony, zostanie on domyślnie określony w bieżącym katalogu.

  • --solution <SOLUTION_PATH>

    Określa ścieżkę pliku rozwiązania do uruchomienia (nazwa folderu lub pełna ścieżka). Jeśli nie zostanie określony, zostanie on domyślnie określony w bieżącym katalogu.

  • --test-modules <EXPRESSION>

    Filtruje moduły testowe przy użyciu funkcji tworzenia globbingu plików na platformie .NET. Zostaną uruchomione tylko testy należące do tych modułów testowych. Aby uzyskać więcej informacji i przykładów dotyczących używania funkcji obsługi globbingu plików na platformie .NET, zobacz Plik globbing.

  • --root-directory <ROOT_PATH>

    Określa katalog główny opcji --test-modules. Można go używać tylko z opcją --test-modules.

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

    Określa maksymalną liczbę modułów testowych, które mogą być uruchamiane równolegle. Wartość domyślna to Environment.ProcessorCount.

  • -a|--arch <ARCHITECTURE>

    Określa architekturę docelową. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --arch x86 ustawia identyfikator RID na win-x86. Jeśli używasz tej opcji, nie używaj opcji -r|--runtime. Dostępne od wersji zapoznawczej 7 platformy .NET 6.

  • -c|--configuration <CONFIGURATION>

    Definiuje konfigurację kompilacji. Wartość domyślna dla większości projektów to Debug, ale można zastąpić ustawienia konfiguracji kompilacji w projekcie.

  • -f|--framework <FRAMEWORK>

    Docelowy pseudonim platformy docelowej (TFM) platformy docelowej do uruchamiania testów. Struktura docelowa musi być również określona w pliku projektu.

  • --os <OS>

    Określa docelowy system operacyjny. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --os linux ustawia identyfikator RID na linux-x64. Jeśli używasz tej opcji, nie używaj opcji -r|--runtime. Dostępne od platformy .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Docelowe środowisko uruchomieniowe do przetestowania.

    Krótki formularz -r dostępny począwszy od zestawu .NET SDK 7.

    Uwaga / Notatka

    Uruchamianie testów dla rozwiązania z właściwością globalną RuntimeIdentifier (jawnie lub za pośrednictwem --archmetody , --runtimelub --os) nie jest obsługiwane. Zamiast tego ustaw RuntimeIdentifier wartość na poziomie pojedynczego projektu.

  • -v|--verbosity <LEVEL>

    Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], m[inimal], n[ormal], d[etailed]i diag[nostic]. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.

  • --no-build

    Określa, że projekt testowy nie jest kompilowany przed uruchomieniem. Ponadto niejawnie ustawia flagę --no-restore.

  • --no-restore

    Określa, że niejawne przywracanie nie jest wykonywane podczas uruchamiania polecenia.

  • --no-ansi

    Wyłącza wyprowadzanie znaków ucieczki ANSI na ekranie.

  • --no-progress

    Wyłącza raportowanie postępu na ekranie.

  • --output <VERBOSITY_LEVEL>

    Określa szczegółowość danych wyjściowych podczas raportowania testów. Prawidłowe wartości to Normal i Detailed. Wartość domyślna to Normal.

  • --no-launch-profile

    Nie próbuj używać launchSettings.json do konfigurowania aplikacji. Domyślnie launchSettings.json jest używany, który może stosować zmienne środowiskowe i argumenty wiersza polecenia do testowego pliku wykonywalnego.

  • --no-launch-profile-arguments

    Nie używaj argumentów określonych w commandLineArgs profilu uruchamiania, aby uruchomić aplikację.

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

    Ustawia co najmniej jedną właściwości programu MSBuild. Określ wiele właściwości, powtarzając opcję:

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

    Krótki formularz -p może być używany dla elementu --property. To samo dotyczy /property:property=value, a jego krótka forma jest /p. Więcej informacji na temat dostępnych argumentów można znaleźć w dokumentacji dotnet msbuild.

  • -?|-h|--help

    Wyświetla opis sposobu używania polecenia .

  • args

    Określa dodatkowe argumenty, które mają być przekazywane do aplikacji testowych. Użyj spacji, aby oddzielić wiele argumentów. Aby uzyskać więcej informacji i przykładów dotyczących przekazywanych informacji, zobacz Microsoft.Testing.Platform overview and Microsoft.Testing.Platform extensions.

    Wskazówka

    Aby określić dodatkowe argumenty dla określonych projektów, użyj właściwości TestingPlatformCommandLineArguments MSBuild.

Uwaga / Notatka

Aby włączyć rejestrowanie śledzenia w pliku, użyj zmiennej środowiskowej DOTNET_CLI_TEST_TRACEFILE, aby podać ścieżkę do pliku śledzenia.

Przykłady

  • Uruchom testy w projekcie lub rozwiązaniu w bieżącym katalogu:

    dotnet test
    
  • Uruchom testy w projekcie TestProject :

    dotnet test --project ./TestProject/TestProject.csproj
    
  • Uruchom testy w rozwiązaniu TestProjects:

    dotnet test --solution ./TestProjects/TestProjects.sln
    
  • Uruchom testy przy użyciu TestProject.dll zestawu:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll"
    
  • Uruchom testy przy użyciu zestawu TestProject.dll z katalogiem głównym:

    dotnet test --test-modules "**/bin/**/Debug/net10.0/TestProject.dll" --root-directory "c:\code"
    
  • Uruchom testy w bieżącym katalogu z pokryciem kodu:

    dotnet test --coverage
    
  • Uruchom testy w projekcieTestProject, podając -bl argument (dziennika binarnego) na :msbuild

    dotnet test --project ./TestProject/TestProject.csproj -bl
    
  • Uruchom testy w projekcie TestProject , ustawiając właściwość MSBuild DefineConstants na DEV:

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

Zobacz także