dotnet test

  • Artykuł
  • Czas czytania: 10 min

Ten artykuł dotyczy: ✔️ zestawu .NET Core 3.1 SDK i jego nowszych wersji

Nazwa

dotnet test — Sterownik testowy .NET używany do wykonywania testów jednostkowych.

Streszczenie

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [-a|--test-adapter-path <ADAPTER_PATH>] [--arch <ARCHITECTURE>]
    [--blame] [--blame-crash]
    [--blame-crash-dump-type <DUMP_TYPE>] [--blame-crash-collect-always]
    [--blame-hang] [--blame-hang-dump-type <DUMP_TYPE>]
    [--blame-hang-timeout <TIMESPAN>]
    [-c|--configuration <CONFIGURATION>]
    [--collect <DATA_COLLECTOR_NAME>]
    [-d|--diag <LOG_FILE>] [-f|--framework <FRAMEWORK>]
    [--filter <EXPRESSION>] [--interactive]
    [-l|--logger <LOGGER>] [--no-build]
    [--nologo] [--no-restore] [-o|--output <OUTPUT_DIRECTORY>] [--os <OS>]
    [-r|--results-directory <RESULTS_DIR>] [--runtime <RUNTIME_IDENTIFIER>]
    [-s|--settings <SETTINGS_FILE>] [-t|--list-tests]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

Opis

Polecenie dotnet test służy do wykonywania testów jednostkowych w danym rozwiązaniu. Polecenie dotnet test tworzy rozwiązanie i uruchamia aplikację hosta testowego dla każdego projektu testowego w rozwiązaniu. Host testowy wykonuje testy w danym projekcie przy użyciu struktury testów, na przykład: MSTest, NUnit lub xUnit, i zgłasza powodzenie lub niepowodzenie każdego testu. Jeśli wszystkie testy zakończą się pomyślnie, program wytłaczania testów zwraca wartość 0 jako kod zakończenia; w przeciwnym razie, jeśli dowolny test zakończy się niepowodzeniem, zwraca wartość 1.

W przypadku projektów o wielu celach testy są uruchamiane dla każdej docelowej struktury. Host testowy i struktury testów jednostkowych są spakowane jako NuGet i są przywracane jako zwykłe zależności dla projektu.

Projekty testowe określają program testowy, używając zwykłego <PackageReference> elementu, jak podano w następującym przykładowym pliku projektu:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.2.0" />
    <PackageReference Include="xunit" Version="2.4.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.4.5" />
  </ItemGroup>

</Project>

Gdzie Microsoft.NET.Test.Sdk jest hostem testowym, xunit jest platformą testową. I xunit.runner.visualstudio jest adapterem testowym, który umożliwia platformie xUnit pracę z hostem testowym.

Niejawne przywracanie

Nie trzeba go uruchamiaćdotnet restore, ponieważ jest on uruchamiany niejawnie przez wszystkie polecenia, które wymagają przywrócenia, dotnet newtakie jak , dotnet build, , dotnet rundotnet test, dotnet publishi dotnet pack. Aby wyłączyć niejawne przywracanie, użyj --no-restore opcji .

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, na przykład kompilacje ciągłej integracji w dotnet restore lub w systemach kompilacji, które muszą jawnie kontrolować czas przywracania.

Aby uzyskać informacje na temat zarządzania NuGet informacyjnymi, zobacz dokumentację.

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie w tle manifestów reklamowych dla obciążeń. Jeśli pobieranie nadal działa po zakończeniu działania tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Advertising manifests (Manifesty reklamy).

Argumenty

  • PROJECT | SOLUTION | DIRECTORY | DLL | EXE

    • Ścieżka do projektu testowego.
    • Ścieżka do rozwiązania.
    • Ścieżka do katalogu zawierającego projekt lub rozwiązanie.
    • Ścieżka do pliku.dll testowego.
    • Ścieżka do pliku.exe testowego.

    Jeśli nie zostanie określony, efekt jest taki sam jak użycie DIRECTORY argumentu do określenia bieżącego katalogu.

Opcje

  • -a|--test-adapter-path <ADAPTER_PATH>

    Ścieżka do katalogu do wyszukania dodatkowych kart testowych. Sprawdzane.dll tylko pliki z sufiksem. Jeśli nie zostanie określony, zostanie przeszukany katalog.dll testowego.

  • --arch <ARCHITECTURE>

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

  • --blame

    Uruchamia testy w trybie blame. Ta opcja jest przydatna w izolowaniu problematycznych testów, które powodują awarię hosta testowego. Po wykryciu awarii program TestResults/<Guid>/<Guid>_Sequence.xml tworzy plik sekwencji w programie , który przechwytuje kolejność testów, które zostały uruchomione przed awarią.

  • --blame-crash (Dostępne od wersji .NET 5.0 SDK)

    Uruchamia testy w trybie blame i zbiera zrzut awaryjny, gdy host testowy nieoczekiwanie kończy działanie. Ta opcja zależy od używanej wersji programu .NET, typu błędu i systemu operacyjnego.

    W przypadku wyjątków w kodzie zarządzanym zrzut zostanie automatycznie zebrany na platformie .NET 5.0 i nowszych wersjach. Spowoduje to wygenerowanie zrzutu dla hosta testhost lub dowolnego procesu podrzędnego, który również był uruchomiony na platformie .NET 5.0 i ulegał awarii. Awarie w kodzie natywnym nie wygeneruje zrzutu. Ta opcja działa w systemach Windows, macOS i Linux.

    Zrzuty awaryjne w kodzie natywnym lub w przypadku korzystania z programu .NET Core 3.1 lub starszych wersji można zbierać tylko w programie Windows przy użyciu programu Procdump. Katalog, który zawiera procdump.exe iprocdump64.exe musi znajdować się w zmiennej środowiskowej PATH PROCDUMP_PATH zmiennej środowiskowej . Pobierz narzędzia. Implikuje --blame.

    Aby zebrać zrzut awaryjne z aplikacji natywnej działającej na platformie .NET 5.0 lub nowszej, użycie programu Procdump VSTEST_DUMP_FORCEPROCDUMP można wymusić, ustawiając zmienną środowiskową na 1.

  • --blame-crash-dump-type <DUMP_TYPE> (Dostępne od wersji .NET 5.0 SDK)

    Typ zrzutu awaryjnego do zebrania. Implikuje --blame-crash.

  • --blame-crash-collect-always (Dostępne od wersji .NET 5.0 SDK)

    Zbiera zrzut awaryjny po oczekiwanym, a także nieoczekiwanym wyjściu z hosta testowego.

  • --blame-hang (Dostępne od wersji .NET 5.0 SDK)

    Uruchom testy w trybie blame i zbierze zrzut zawieszania, gdy test przekroczy podany limit czasu.

  • --blame-hang-dump-type <DUMP_TYPE> (Dostępne od wersji .NET 5.0 SDK)

    Typ zrzutu awaryjnego do zebrania. Powinna to być full, minilub none. Jeśli none jest określony, hosta testowego kończy się po przeoczanie limitu czasu, ale zrzut nie jest zbierany. Implikuje --blame-hang.

  • --blame-hang-timeout <TIMESPAN> (Dostępne od wersji .NET 5.0 SDK)

    Limit czasu dla testu, po którym jest wyzwalany zrzut zawieszania, a proces hosta testowego i wszystkie jego procesy podrzędne są zrzucane i przerywane. Wartość limitu czasu jest określona w jednym z następujących formatów:

    • 1,5 godz., 1,5 godz., 1,5 godz.
    • 90 m, 90 minut, 90 minut, 90 minut
    • 5400 s, 5400 s, 5400sekundy, 5400 ssekund
    • 5400000ms, 5400000mil, 54000000millisecond, 54000000milliseconds

    Jeśli nie jest używana żadna jednostka (na przykład 54000000), przyjmuje się, że wartość jest w milisekundach. W przypadku korzystania z testów opartych na danych zachowanie limitu czasu zależy od używanego adaptera testowego. W przypadku jednostek xUnit i NUnit limit czasu jest odnawiany po każdym przypadku testowym. W przypadku programu MSTest limit czasu jest używany we wszystkich przypadkach testowych. Ta opcja jest obsługiwana na komputerach Windows i netcoreapp2.1 nowszych wersjach, w systemie Linux z netcoreapp3.1 systemem i nowszym oraz w systemie macOS z net5.0 systemem lub nowszym. Implikuje --blame i --blame-hang.

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

  • --collect <DATA_COLLECTOR_NAME>

    Włącza moduł zbierający dane dla uruchomienia testowego. Aby uzyskać więcej informacji, zobacz Monitorowanie i analizowanie przebiegów testów.

    Aby zbierać pokrycie kodu na dowolnej platformie obsługiwanej przez platformę .NET Core, zainstaluj program Coverlet i użyj opcji .

    Na Windows można zbierać pokrycie kodu przy użyciu --collect "Code Coverage" opcji . Ta opcja generuje plik coverage, który można otworzyć w Visual Studio 2019 Enterprise. Aby uzyskać więcej informacji, zobacz Korzystanie z pokrycia kodu iDostosowywanie analizy pokrycia kodu.

  • -d|--diag <LOG_FILE>

    Włącza tryb diagnostyczny dla platformy testowej i zapisuje komunikaty diagnostyczne do określonego pliku i do plików obok niej. Proces rejestrowania komunikatów określa, które pliki są tworzone, *.host_<date>.txt na przykład dla dziennika hosta testowego i *.datacollector_<date>.txt dziennika modułu zbierającego dane.

  • -f|--framework <FRAMEWORK>

    Moniker struktury docelowej (TFM) docelowej struktury do uruchamiania testów. Platformę docelową należy również określić w pliku projektu.

  • --filter <EXPRESSION>

    Odfiltrowuje testy w bieżącym projekcie przy użyciu danego wyrażenia. Aby uzyskać więcej informacji, zobacz sekcję Szczegóły opcji filtrowania. Aby uzyskać więcej informacji i przykładów dotyczących używania selektywnego filtrowania testów jednostkowych, zobacz Uruchamianie selektywnych testów jednostkowych.

  • -?|-h|--help

    Drukuje opis sposobu korzystania z polecenia.

  • --interactive

    Umożliwia polecenie zatrzymania i oczekiwania na dane wejściowe użytkownika lub akcję. Na przykład w celu ukończenia uwierzytelniania. Dostępne od wersji .NET Core 3.0 SDK.

  • -l|--logger <LOGGER>

    Określa rejestrator wyników testów. W MSBuild, dotnet test nie akceptuje skrótów: zamiast -l "console;v=d" używać .-l "console;verbosity=detailed" Określ parametr wielokrotnie, aby włączyć wiele rejestratorów. Aby uzyskać więcej informacji, zobacz Raportowanie wyników testów, Przełączniki rejestratorów i przykłady w dalszej części tego artykułu.

  • --no-build

    Nie tworzy projektu testowego przed jego uruchomieniem. Ponadto niejawnie ustawia flagę - --no-restore .

  • --nologo

    Uruchamiaj testy bez wyświetlania transparentu Microsoft TestPlatform. Dostępne od wersji .NET Core 3.0 SDK.

  • --no-restore

    Nie wykonuje niejawnego przywracania podczas uruchamiania polecenia.

  • -o|--output <OUTPUT_DIRECTORY>

    Katalog, w którym można znaleźć pliki binarne do uruchomienia. Jeśli nie zostanie określony, ścieżka domyślna to ./bin/<configuration>/<framework>/. W przypadku projektów z wieloma platformami docelowymi (za pośrednictwem TargetFrameworks właściwości) --framework należy również zdefiniować podczas określania tej opcji. dotnet test Zawsze uruchamia testy z katalogu wyjściowego. Umożliwia korzystanie z AppDomain.BaseDirectory zasobów testowych w katalogu wyjściowym.

  • --os <OS>

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

  • -r|--results-directory <RESULTS_DIR>

    Katalog, w którym zostaną umieszczone wyniki testu. Jeśli określony katalog nie istnieje, zostanie utworzony. Wartość domyślna TestResults znajduje się w katalogu, który zawiera plik projektu.

  • --runtime <RUNTIME_IDENTIFIER>

    Docelowe środowisko uruchomieniowe do testowania.

  • -s|--settings <SETTINGS_FILE>

    Plik .runsettings do użycia do uruchamiania testów. Element TargetPlatform (x86|x64) nie ma wpływu na .dotnet test Aby uruchomić testy dla wersji x86, zainstaluj wersję x86 programu .NET Core. Bitowość dotnet.exe, która znajduje się w ścieżce, będzie używana do uruchamiania testów. Więcej informacji można znaleźć w następujących zasobach:

  • -t|--list-tests

    Zamiast uruchamiać testy, należy wyświetlić listę odnalezionych testów.

  • -v|--verbosity <LEVEL>

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

  • args

    Określa dodatkowe argumenty do przekazania do karty. Użyj spacji, aby oddzielić wiele argumentów.

    Lista możliwych argumentów zależy od określonego zachowania:

    • Jeśli określisz projekt, rozwiązanie lub katalog albo pominiesz ten argument, wywołanie zostanie przekazane do .msbuild W takim przypadku dostępne argumenty można znaleźć w dokumentacji dotnet msbuild.
    • Po określeniu .dll lub .exewywołanie jest przekazywane do . W takim przypadku dostępne argumenty można znaleźć w dokumentacji dotnet vstest.

  • RunSettings Argumenty

Wbudowane są RunSettings przekazywane jako ostatnie argumenty w wierszu polecenia po ciągu "--" (zwróć uwagę na spację po --). Wbudowane są RunSettings określane jako [name]=[value] pary. Spacja służy do oddzielania wielu [name]=[value] par.

Przykład: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Aby uzyskać więcej informacji, zobacz Przekazywanie argumentów RunSettings za pośrednictwem wiersza polecenia.

Przykłady

  • Uruchom testy w projekcie w bieżącym katalogu:

    dotnet test

  • Uruchom testy w test1 projekcie:

    dotnet test ~/projects/test1/test1.csproj

  • Uruchom testy przy użyciu zestawu test1.dll :

    dotnet test ~/projects/test1/bin/debug/test1.dll

  • Uruchom testy w projekcie w bieżącym katalogu i wygeneruj plik wyników testu w formacie trx:

    dotnet test --logger trx

  • Uruchom testy w projekcie w bieżącym katalogu i wygeneruj plik pokrycia kodu (po zainstalowaniu integracji modułów zbierających Coverlet ):

    dotnet test --collect:"XPlat Code Coverage"

  • Uruchom testy w projekcie w bieżącym katalogu i wygeneruj plik pokrycia kodu (tylko Windows kodu):

    dotnet test --collect "Code Coverage"

  • Uruchom testy w projekcie w bieżącym katalogu i zaloguj się ze szczegółowymi informacjami w konsoli:

    dotnet test --logger "console;verbosity=detailed"

  • Uruchom testy w projekcie w bieżącym katalogu i zaloguj się za pomocą rejestratora trx do pliku testResults.trx w folderze TestResults :

    dotnet test --logger "trx;logfilename=testResults.trx"

    Ponieważ nazwa pliku dziennika jest określona, ta sama nazwa jest używana dla każdej struktury docelowej w przypadku projektu o wielu celach. Dane wyjściowe dla każdej struktury docelowej zastępują dane wyjściowe dla poprzednich platform docelowych. Plik jest tworzony w folderze TestResults w folderze projektu testowego, ponieważ ścieżki względne są względne względem tego folderu. W poniższym przykładzie pokazano, jak utworzyć oddzielny plik dla każdej struktury docelowej.

  • Uruchom testy w projekcie w bieżącym katalogu i zaloguj się za pomocą rejestratora trx do plików w folderze TestResults o nazwach plików, które są unikatowe dla każdej struktury docelowej:

    dotnet test --logger:"trx;LogFilePrefix=testResults"

  • Uruchom testy w projekcie w bieżącym katalogu i zaloguj się za pomocą rejestratora html, abytestResults.htmlw folderze TestResults :

    dotnet test --logger "html;logfilename=testResults.html"

  • Uruchom testy w projekcie w bieżącym katalogu i zgłoś testy, które były w toku, gdy host testowy ulegał awarii:

    dotnet test --blame

  • Uruchom testy w projekcietest1, podając -bl argument (dziennik binarny) do :msbuild

    dotnet test ~/projects/test1/test1.csproj -bl

  • Uruchom testy w projekcietest1, ustawiając właściwość MSBuild DefineConstants na wartość DEV:

    dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"

Szczegóły opcji filtrowania

--filter <EXPRESSION>

<Expression> ma format <property><operator><value>[|&<Expression>].

<property>jest atrybutem .Test Case Poniżej przedstawiono właściwości obsługiwane przez popularne struktury testów jednostkowych:

Test Framework Obsługiwane właściwości
MSTest
  • FullyQualifiedName
  • Nazwa
  • ClassName
  • Priorytet
  • TestCategory
xUnit
  • FullyQualifiedName
  • Nazwa wyświetlana
  • Kategoria
NUnit
  • FullyQualifiedName
  • Nazwa
  • TestCategory
  • Priorytet

Opisuje <operator> relację między właściwością i wartością:

Operator Funkcja
= Pełna zgodność
!= Niedokładne dopasowanie
~ Contains
!~ Nie zawiera

<value> jest ciągiem. We wszystkich wyszukiwaniach nie jest roz rozwrażliwa na literę.

Wyrażenie bez obiektu jest <operator> automatycznie uznawane za właściwość contains on FullyQualifiedName (na przykład dotnet test --filter xyz jest takie samo jak dotnet test --filter FullyQualifiedName~xyzwyrażenie ).

Wyrażenia można łączyć za pomocą operatorów warunkowych:

Operator Funkcja
| LUB
& AND

Wyrażenia można ująć w nawiasy, używając operatorów warunkowych (na przykład (Name~TestMethod1) | (Name~TestMethod2)).

Aby uzyskać więcej informacji i przykładów dotyczących używania selektywnego filtrowania testów jednostkowych, zobacz Uruchamianie selektywnych testów jednostkowych.

Zobacz też