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

Artykuł dotyczy: ✔️ .NET 10 sdk i nowszych wersji

Name

dotnet test — .NET sterownik testowy używany do wykonywania testów jednostkowych za pomocą protokołu MTP.

Streszczenie

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

W przypadku protokołu MTP 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 testowych project. Ponadto protokół MTP obsługuje filtr globbingu podczas uruchamiania testów. Aby uzyskać więcej informacji, zobacz MTP.

Ważna

Opcje specyficzne dla rozszerzenia nie są wbudowane w MTP. Każda docelowa aplikacja testowa musi zarejestrować rozszerzenie, które zapewnia opcję. Dodaj pakiet NuGet rozszerzenia bezpośrednio lub użyj testowej konfiguracji zestawu SDK lub profilu zawierającego pakiet. W przeciwnym razie przebieg testu kończy się niepowodzeniem z kodem zakończenia 5, ponieważ opcja jest nierozpoznana. Uruchom polecenie , dotnet test --help aby wyświetlić opcje dostępne dla wybranych aplikacji testowych i zobacz Opcje rozszerzenia według scenariusza , aby znaleźć pakiet dla opcji.

Ostrzeżenie

Gdy MTP jest włączona za pośrednictwem programu global.json, dotnet test oczekuje, że wszystkie projekty testowe będą korzystać z protokołu MTP. Jest to błąd, jeśli którykolwiek z projektów testowych używa narzędzia VSTest.

Wymagania dotyczące wersji

Tryb dotnet test MTP wymaga zestawu SDK .NET 10 i protokołu MTP 1.7 lub nowszego. Opcje dodane po .NET 10 mają indywidualne wymagania dotyczące wersji zestawu SDK w poniższych sekcjach. Niektóre opcje wymagają również nowszego pakietu MTP, ponieważ zestaw SDK koordynuje pełny przebieg, podczas gdy każda aplikacja testowa implementuje odpowiednie możliwości.

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 ma sens, takich jak kontynualne kompilacje integracji w usługach Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy nastąpi przywracanie.

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

Ważna

Po uruchomieniu projektu lub rozwiązania --no-restorez programem zachowaj stan projektu generowanego przez przywracanie w obj folderze i pasujący folder pakietów globalnych. Importowanie platformy testowej i pakietu platformy ustawia właściwości programu MSBuild używane dotnet test do identyfikowania aplikacji testowych MTP. Opcja --no-build oznacza --no-restorerównież . Jeśli środowisko testowe zawiera skompilowane aplikacje testowe, ale nie stan przywracania projektu, użyj --test-modules zamiast tego. Aby uzyskać więcej informacji, zobacz No test projects were found.

Opcje

Uwaga / Notatka

Jednocześnie można użyć tylko jednej z następujących opcji: --project, --solution lub --test-modules. Tych opcji nie można połączyć. Ponadto w przypadku używania polecenia --test-modulesnie można określić --arch, , --list-devices--configuration--framework--os--device--runtimelub .--use-current-runtime Te opcje wymagają oceny projektu lub nie są istotne dla już utworzonego modułu.

  • PROJECT_OR_TRAVERSAL_PATH

    Określa projekt lub projekt przechodzenia do uruchomienia. Począwszy od .NET 11 (wersja zapoznawcza 7), dotnet test obsługuje Microsoft.Build.Traversal projekty, takie jak dirs.proj, i cyklicznie uruchamiają przywoływalne projekty testowe.

    Począwszy od .NET 12 (wersja zapoznawcza 1), argument może również zidentyfikować aplikację testową MTP opartą na plikach języka C#. Aplikacje testowe oparte na plikach nie obsługują --deviceprogramu .

  • --project <PROJECT_PATH>

    Określa ścieżkę pliku project 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. Uruchamiane są tylko testy należące do tych modułów testowych. Ponieważ ta opcja nie ocenia projektów, użyj jej do uruchamiania już skompilowanych aplikacji testowych, gdy stan przywracania projektu jest niedostępny. Począwszy od .NET 11 (wersja zapoznawcza 6), prefiks wzorca z elementem ! wykluczania pasujących modułów. Rozdziel wiele wzorców średnikami; odstępy wokół każdego wzorca są ignorowane.

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

  • --config-file <CONFIG_FILE>

    Określa plik konfiguracji, który ma być używany do wykonywania testów. Jeśli podano ścieżkę względną, jest konwertowana na ścieżkę bezwzględną na podstawie bieżącego katalogu. Aby uzyskać więcej informacji na temat ustawień pliku konfiguracji, zobacz testconfig.json.

  • --results-directory <RESULTS_DIRECTORY>

    Określa katalog, w którym są przechowywane wyniki testów. Jeśli katalog nie istnieje, zostanie utworzony. Jeśli podano ścieżkę względną, jest konwertowana na ścieżkę bezwzględną na podstawie bieżącego katalogu.

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

    Określa sposób uruchamiania wielu modułów organizuje pliki w katalogu wyników. Wartość domyślna , flatzapisuje wszystkie wyniki w tym samym katalogu. per-module Zapisuje wyniki każdego modułu w pliku <project>/<target-framework>_<runtime-or-architecture>, co uniemożliwia raportom o tej samej nazwie pliku zastąpienie siebie nawzajem.

    Dostępne od .NET 11 RC 1.

  • --diagnostic-output-directory <DIAGNOSTIC_OUTPUT_DIRECTORY>

    Określa katalog, w którym są przechowywane dane wyjściowe diagnostyki. Jeśli katalog nie istnieje, zostanie utworzony. Jeśli podano ścieżkę względną, jest konwertowana na ścieżkę bezwzględną na podstawie bieżącego katalogu.

  • --minimum-expected-tests <NUMBER>

    Określa dodatnią minimalną liczbę testów dla całego przebiegu. Jeśli zagregowana liczba testów jest mniejsza niż określona minimalna, przebieg testu zakończy się niepowodzeniem z kodem zakończenia 9. Liczba globalna obejmuje pominięte testy. Aby uzyskać więcej informacji na temat kodów zakończenia, zobacz Kody zakończenia MTP.

    Ponieważ ta opcja jest wyświetlana przed --, jest to opcja globalna (cały przebieg). Aby zamiast tego wymagać minimum dla każdego modułu testowego, należy przekazać tę opcję po -- jej przekazaniu do każdego modułu testowego. Aby uzyskać więcej informacji, zobacz Minimum całego uruchomienia i poszczególnych modułów.

    Uwaga / Notatka

    Minimum globalne wymaga zestawu SDK .NET 10 (10.0.100) lub nowszej wersji.

  • --maximum-failed-tests <NUMBER>

    Zatrzymuje pełny przebieg po osiągnięciu określonej liczby zakończonych niepowodzeniem, błędów, przekroczenia limitu czasu lub anulowanych testów. Przebieg kończy działanie z kodem 13.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 7) i wymagają protokołu MTP 2.4 lub nowszego.

  • --timeout <DURATION>

    Zatrzymuje pełny przebieg po określonym czasie trwania, gdy co najmniej jedna aplikacja testowa jest uruchomiona. Określ liczbę dodatnią, po której następuje jednostka, na przykład 500ms, 90s, 10m, 2hlub 1d. Przekroczenie limitu czasu kończy działanie z kodem 3.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 7) i wymagają protokołu MTP 2.4 lub nowszego.

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

    Ustawia zmienną środowiskową dla procesu testowego. Określ opcję wiele razy, aby ustawić wiele zmiennych. Wartości wiersza polecenia zastępują wartości z profilu uruchamiania.

    Użyj zestawu .NET SDK 10.0.110 lub nowszego, jeśli profil uruchamiania nie istnieje lub po określeniu --no-launch-profile; wcześniejsze .NET 10 wersji zestawu SDK mogą ignorować zmienne w tych przypadkach. Począwszy od .NET 11 (wersja zapoznawcza 7), zmienne również przepływają do kompilacji obsługującej możliwości, wyboru urządzenia, wdrożenia i elementów docelowych argumentów uruchamiania.

  • -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 .NET 6 (wersja zapoznawcza 7).

  • --artifacts-path <ARTIFACTS_DIR>

    Wszystkie pliki wyjściowe kompilacji z wykonanego polecenia zostaną umieszczone w podfolderach w określonej ścieżce oddzielonej przez projekt. Aby uzyskać więcej informacji, zobacz Artifacts Output Layout. Ta opcja i podana wartość muszą być jawnie kaskadowe w dowolnym dotnet poleceniu, które zależy od danych wyjściowych innego dotnet polecenia, na przykład w przypadku użycia dotnet build --no-restore i dotnet publish --no-build. Dostępne od .NET 8 zestawu SDK.

    Dostępny dla trybu MTP rozpoczynający się od .NET 11.

  • -c|--configuration <CONFIGURATION>

    Definiuje konfigurację kompilacji. Ustawieniem domyślnym dla większości projektów jest Debug, ale ustawienia konfiguracji kompilacji można zastąpić w project.

  • -f|--framework <FRAMEWORK>

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

  • --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 .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. Ustaw RuntimeIdentifier na poziomie pojedynczego project.

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

    Używa bieżącego środowiska uruchomieniowego jako docelowego środowiska uruchomieniowego podczas przywracania i kompilacji.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 6). Nie można połączyć tej opcji z opcją --test-modules.

  • -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 test project nie jest kompilowany przed uruchomieniem. Ponadto niejawnie ustawia flagę --no-restore.

  • --no-dependencies

    Pomija tworzenie odwołań do projektu.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 6).

  • --no-restore

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

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

    Pomija banery uruchamiania .NET i MTP. Obsługiwane -nologo są również formularze i /nologo oraz zmienna DOTNET_NOLOGO środowiskowa.

    Dostępne w trybie MTP, począwszy od wersji .NET 11 (wersja zapoznawcza 7).

  • --no-ansi

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

  • --no-progress

    Wyłącza raportowanie postępu na ekranie.

  • --no-artifact-post-processing

    Wyłącza przetwarzanie po zakończeniu przetwarzania zgodnych artefaktów po uruchomieniu wielu modułów. Począwszy od .NET 11 RC 1 i MTP 2.4, zarejestrowane procesory artefaktów mogą łączyć zgodne raporty, takie jak wyniki TRX. Jeśli przetwarzanie końcowe zakończy się niepowodzeniem, zestaw SDK zachowuje oryginalne artefakty i kod zakończenia testu.

  • --output <VERBOSITY_LEVEL>

    Określa szczegółowość danych wyjściowych dla wyników testu. Prawidłowe wartości to Minimal, Normal i Detailed. Wartość domyślna to Normal. Minimal Wymaga protokołu MTP 2.4 (wersja zapoznawcza).

  • --show-test-results <OUTCOME>

    Wybiera bloki wyników według wyniku. W wersji zapoznawczej MTP 2.4 użyj polecenia passed, failed, skipped, alllub none. Wartość failed obejmuje również błędy, przekroczenia limitu czasu i anulowania.

    Połącz passedwartości , failedi skipped z przecinkami, spacjami lub wielokrotnymi --show-test-results opcjami. Nie należy łączyć all ani none z inną wartością. Ta jawna opcja zastępuje --output ustawienie wstępne niezależnie od kolejności opcji.

  • --list-tests [text|json]

    Wyświetla listę odnalezionych testów bez ich wykonywania. Pomiń wartość lub określ text dane wyjściowe czytelne dla człowieka. Począwszy od .NET 11 (wersja zapoznawcza 7), określ json dla dokumentu JSON w wersji, który grupuje testy według zestawu, platformy docelowej i architektury oraz zawiera dostępne identyfikatory, lokalizacje źródłowe, metody, parametry i cechy.

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

  • --device <DEVICE_ID>

    Wybiera urządzenie, emulator lub symulator dla każdej platformy docelowej w projekcie testowym systemu Android lub iOS. Ścieżka MTP obsługuje również projekty testowe systemu macOS i Mac Catalyst. Jeśli dane wejściowe są interaktywne, a więcej niż jedno urządzenie jest dostępne, dotnet test może wyświetlić monit o wybranie jednego urządzenia.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 6). W przypadku projektów wielokierunkowych należy użyć .NET 11 RC 2 lub nowszej, aby funkcja odnajdywania urządzeń prawidłowo oceniała każdą platformę docelową. Ta opcja nie obsługuje projektów testowych zestawu WebAssembly przeglądarki.

  • --list-devices

    Wyświetla listę dostępnych urządzeń dla projektu bez uruchamiania testów. Określ projekt, a nie rozwiązanie.

    Dostępne od wersji .NET 11 (wersja zapoznawcza 7).

  • --collect-test-map i --affected-tests

    Zbierz mapę testową repozytorium lub uruchom testy, których dotyczy zmiana. Te opcje eksperymentalne wymagają oddzielnego rozszerzenia rozproszonego i zmiennej środowiskowej DOTNET_CLI_ENABLE_AFFECTED_TESTS=1 . Nie można połączyć tych dwóch opcji. Przepływy pracy testów, których dotyczy problem, nie obsługują również testowania urządzeń, modułów testów równoległych ani zasad testu minimalnego.

    Dostępne od .NET 11 RC 1.

  • --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 MTP overview and MTP features (Omówienie MTP i funkcje MTP).

    Wskazówka

    Aby określić dodatkowe argumenty dla określonych projektów, użyj właściwości TestingPlatformCommandLineArguments MSBuild. Ta właściwość jest szczególnie przydatna, gdy rozwiązanie miesza struktury testowe (na przykład MSTest i xUnit.net) lub gdy tylko niektóre projekty odwołują się do określonego rozszerzenia. Aby uzyskać więcej informacji, zobacz Rozwiązania z mieszanymi strukturami testowymi lub rozszerzeniami.

Uwaga / Notatka

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

Począwszy od .NET 11 RC 1, dotnet test -bl używa jednej sesji MSBuild dla wielu projektów, wielokierunkowych i uruchomionych urządzeń, aby dziennik binarny zawierał pełną kompilację.

Zachowanie danych wyjściowych i anulowania

Począwszy od .NET 11 (wersja zapoznawcza 6), interaktywne dane wyjściowe ANSI pokazują testy, które są obecnie uruchomione i raporty dotyczące liczby testów dla zestawu. Wyświetlanie postępu pozostaje wyłączone, gdy dane wyjściowe są przekierowywane, ansi lub dane wyjściowe postępu są wyłączone lub środowisko nie jest interaktywne.

Począwszy od .NET 11 (wersja zapoznawcza 6), pierwszy klawisz Ctrl+C zatrzymuje planowanie nowych aplikacji testowych i żąda anulowania współpracy. Naciśnij ponownie klawisze Ctrl+C , aby natychmiast zakończyć procesy podrzędne. Przerwane uruchomienie kończy działanie z kodem 3.

Dane wyjściowe live test-host wymagają hosta MTP obsługującego protokół 1.1 lub nowszy. Starsze hosty zachowują przechwycone dane wyjściowe i powtarzają je dla modułu, który zakończył się niepowodzeniem. Począwszy od .NET 11 (wersja zapoznawcza 7), podsumowania błędów obcinają przechwycone standardowe dane wyjściowe dłuższe niż 40 wierszy do pierwszych 30 i ostatnich 10 wierszy; dzienniki diagnostyczne zachowują pełne dane wyjściowe.

W przypadku przebiegów dotnet test z wieloma modułami ocenia wynik testu zerowego w całym przebiegu rozpoczynającym się od .NET 11 (wersja zapoznawcza 7). Moduł bez testów nie kończy się niepowodzeniem, jeśli inny moduł wykonuje testy pomyślnie, chyba że jawne zasady testu minimalnego wymagają większej liczby testów.

Wyniki i artefakty

Po włączeniu układu wyjściowego artefaktów zestawu SDK .NET 11 RC 1 i nowszych wersjach domyślnie umieszczaj raporty MTP, pliki pokrycia i diagnostykę<ArtifactsPath>/test/<project>/<pivot>. --results-directory Jawne lub --results-directory-layout ma pierwszeństwo.

Począwszy od .NET 11 RC 1 i MTP 2.4, zgodne rozszerzenia mogą przetwarzać artefakty po przetworzeniu z uruchomienia wielu modułów. Na przykład rozszerzenie TRX może utworzyć scalony raport przy zachowaniu raportów dla poszczególnych modułów. Aby uzyskać informacje o wymaganiach dotyczących rozszerzeń i raportów, zobacz Raporty testowe MTP.

Przekazywanie argumentów do aplikacji testowej

dotnet test przekazuje token, który nie rozpoznaje aplikacji testowej. Gdy rozpoznana opcja pojawia się między nierozpoznaną nazwą opcji a jej wartością, usunięcie rozpoznanej opcji może zmienić sposób powiązania tokenów pozostałych z opcjami w aplikacji testowej. Aby uniknąć tej niejednoznaczności, umieść argumenty aplikacji testowej po literału --:

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

W poprzednim przykładzie wymagany jest Microsoft.Testing.Extensions.TrxReport pakiet jako bezpośrednia dokumentacja pakietu lub konfiguracja zestawu SDK testowego, która go zawiera.

To samo zachowanie analizatora dotyczy dotnet run elementów i dotnet build. Aby uzyskać szczegółowy przykład, zobacz Przekazywanie argumentów do aplikacji w odwołaniu dotnet run .

Minimum całego przebiegu i modułu

W przypadku --minimum-expected-testsseparatora -- określa zakres opcji:

  • Argumenty przed-- są globalne. Orkiestrator dotnet test interpretuje je dla całego przebiegu.
  • Argumenty po-- są lokalne. dotnet test przekazuje je do każdego modułu testowego, więc każdy moduł stosuje je niezależnie.

Ponieważ --minimum-expected-tests jest dostępny w obu zakresach, można wymagać minimum dla całego przebiegu, dla każdego modułu lub obu tych elementów:

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

Poprzednie polecenie wymaga co najmniej 5 testów w całym przebiegu i co najmniej 2 testy w każdym module testowym.

Liczba dwóch zakresów pominiętych testów różnie:

Scope Czy pominięte testy są liczone w kierunku minimum?
Globalny Yes. Zagregowana dotnet test suma obejmuje pominięte testy.
Na moduł No. MTP wyklucza pominięte testy z liczby uruchomionych testów.

Począwszy od zestawu SDK .NET 11, werdykt zero-testów dla całego przebiegu jest ustalany raz z zagregowanych wyników. Moduł, który nie pasuje do żadnych testów, na przykład z powodu --test-modules lub globalnego --filter, kończy działanie z kodem 8 (ZeroTests), ale ten kod jest znormalizowany do powodzenia, zanim wyniki zostaną zagregowane. W związku z tym pojedynczy pusty moduł nie kończy się niepowodzeniem całego przebiegu, chociaż moduł zachowuje diagnostykę Exit code: 8 w danych wyjściowych w celu uzyskania widoczności.

Wersje MTP 4.3.0 i nowsze zapewniają .--zero-tests-policy <allow-skipped|strict> Wartość domyślna , allow-skippedumożliwia pomyślne pominięcie modułu. Wartość strict traktuje pominięte testy jako nie uruchamiane, więc pominięty moduł kończy działanie z kodem 8. Przekaż opcję po -- przekazaniu jej do każdego modułu testowego:

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

Jeśli nie ustawisz globalnego minimum, zestaw SDK .NET 11 określa oddzielnie cały werdykt bez testów. Wszystkie pominięte cały przebieg kończy się z kodem 8 niezależnie od wartości modułu --zero-tests-policy .

Po określeniu --minimum-expected-tests wartości minimalnej i minimalnej przebieg kończy się niepowodzeniem z kodem zakończenia 9 (MinimumExpectedTestsPolicyViolation). Ten kod różni się od 8, dzięki czemu bardziej globalny lub minimalny dla modułu nie jest mylony z pustym modułem. Aby minimalna liczba modułów zwracała kod 9, gdy moduł uruchamia testy zerowe, moduł testowy musi używać protokołu MTP 4.4.0 lub nowszej.

Uwaga / Notatka

--minimum-expected-tests 0 jest nieprawidłowy. Aby pominąć kod zakończenia testów zerowych, użyj polecenia --ignore-exit-code 8.

Począwszy od .NET 11 (wersja zapoznawcza 6), --tl, --terminalloggeri --tlp są przekazywane do programu MSBuild zamiast aplikacji testowej. Począwszy od .NET 12 (wersja zapoznawcza 1), rozpoznane -mt formularze i -multiThreaded są również przekazywane do programu MSBuild. Aby przekazać opcję aplikacji z jedną z tych nazw, umieść ją po --.

Przekaż opcje trybu wykonywania, takie jak --help i --list-tests bezpośrednio do dotnet test. Począwszy od .NET 11 (wersja zapoznawcza 6), zestaw SDK weryfikuje tryb wykonywania wynegocjowany z aplikacją testowaną. Jeśli profil uruchamiania lub TestingPlatformCommandLineArguments wprowadza jedną z tych opcji, żądana operacja zestawu SDK i operacja aplikacji nie są zgodne, a przebieg kończy się niepowodzeniem z diagnostyką.

Przykłady

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

    dotnet test
    
  • Uruchom testy w TestProject project:

    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 wszystkie projekty testowe, do których odwołuje się projekt przechodzenia z .NET 11 (wersja zapoznawcza 7 lub nowsza):

    dotnet test dirs.proj
    
  • Wyświetl listę testów jako kod JSON z .NET 11 (wersja zapoznawcza 7 lub nowsza):

    dotnet test --list-tests json
    
  • Uruchom aplikację testową MTP opartą na plikach języka C# z .NET 12 (wersja zapoznawcza 1 lub nowsza):

    dotnet test App.Tests.cs
    
  • Uruchom testy w bieżącym katalogu z rozszerzeniem pokrycia kodu Microsoft. Aplikacja testowa musi odwoływać się Microsoft.Testing.Extensions.CodeCoveragebezpośrednio lub za pośrednictwem konfiguracji zestawu SDK testowego, która zawiera następujące elementy:

    dotnet test --coverage
    
  • Uruchom testy i zapisz wyniki w określonym katalogu:

    dotnet test --results-directory ./TestResults
    
  • Uruchom testy z danymi wyjściowymi diagnostycznymi w określonym katalogu:

    dotnet test --diagnostic-output-directory ./Diagnostics
    
  • Uruchom testy zapewniające wykonanie co najmniej 10 testów:

    dotnet test --minimum-expected-tests 10
    
  • Wymagaj co najmniej 5 testów w całym przebiegu i co najmniej 2 testy w każdym module testowym:

    dotnet test --minimum-expected-tests 5 -- --minimum-expected-tests 2
    
  • Uruchom testy w TestProject project, podając argument -bl (dziennik binarny), aby msbuild:

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

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

Zobacz także