dotnet test

Artykuł
03/27/2024

Ten artykuł dotyczy: ✔️ zestaw .NET Core 3.1 SDK i nowsze wersje

Nazwisko

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

Streszczenie

dotnet test [<PROJECT> | <SOLUTION> | <DIRECTORY> | <DLL> | <EXE>]
    [--test-adapter-path <ADAPTER_PATH>]
    [-a|--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>]
    [-e|--environment <NAME="VALUE">]
    [--filter <EXPRESSION>]
    [--interactive]
    [-l|--logger <LOGGER>]
    [--no-build]
    [--nologo]
    [--no-restore]
    [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>]
    [--results-directory <RESULTS_DIR>]
    [-r|--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 kompiluje rozwiązanie i uruchamia testową aplikację hosta dla każdego projektu testowego w rozwiązaniu. Host testowy wykonuje testy w danym projekcie przy użyciu platformy testowej, na przykład: MSTest, NUnit lub xUnit oraz zgłasza powodzenie lub niepowodzenie każdego testu. Jeśli wszystkie testy zakończą się pomyślnie, moduł uruchamiający testy zwróci wartość 0 jako kod zakończenia; w przeciwnym razie, jeśli jakikolwiek test zakończy się niepowodzeniem, zwraca wartość 1.

W przypadku projektów wielokierunkowych testy są uruchamiane dla każdej platformy docelowej. Host testowy i struktura testów jednostkowych są pakowane jako pakiety NuGet i są przywracane jako zwykłe zależności dla projektu. Począwszy od zestawu .NET 9 SDK, te testy są uruchamiane równolegle. Aby wyłączyć wykonywanie równoległe, ustaw TestTfmsInParallel właściwość MSBuild na false. Aby uzyskać więcej informacji, zobacz Uruchamianie testów równolegle i przykładowy wiersz polecenia w dalszej części tego artykułu.

Projekty testowe określają moduł uruchamiający testy przy użyciu zwykłego <PackageReference> elementu, jak pokazano w następującym przykładowym pliku projektu:

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

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.9.0" />
    <PackageReference Include="xunit" Version="2.7.1" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.8" />
  </ItemGroup>

</Project>

Gdzie Microsoft.NET.Test.Sdk jest hostem testowym, xunit to platforma testowa. Jest xunit.runner.visualstudio to karta testowa, która umożliwia pracę platformy xUnit z hostem testowym.

Niejawne przywracanie

Nie trzeba uruchamiaćdotnet restore, ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, , dotnet build, dotnet rundotnet test, , dotnet publish, i 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, takie jak kompilacje ciągłej 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.

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

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 projektu testowego.
- Ścieżka do pliku .exe projektu testowego.
Jeśli nie zostanie określony, efekt jest taki sam jak użycie argumentu DIRECTORY w celu określenia bieżącego katalogu.

Opcje

Ostrzeżenie

Zmiany powodujące niezgodność w opcjach:

Począwszy od platformy .NET 7: przełącz -a się do aliasu --arch zamiast --test-adapter-path
Począwszy od platformy .NET 7: przełącz -r się do aliasu --runtime zamiast --results-directory

--test-adapter-path <ADAPTER_PATH>

Ścieżka do katalogu do wyszukania dodatkowych kart testowych. Sprawdzane są tylko pliki .dll z sufiksem .TestAdapter.dll . Jeśli nie zostanie określony, przeszukiwany jest katalog .dll testowej.

Krótki formularz -a dostępny w wersjach zestawu .NET SDK starszych niż 7.

--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-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . Dostępne od wersji zapoznawczej 7 platformy .NET 6.

--blame

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

Ta opcja nie tworzy zrzutu pamięci i nie jest pomocna podczas zawieszania się testu.
--blame-crash (Dostępne od zestawu .NET 5.0 SDK)

Uruchamia testy w trybie winy i zbiera zrzut awaryjny, gdy host testowy kończy nieoczekiwanie działanie. Ta opcja zależy od używanej wersji platformy .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 testowego lub dowolnego procesu podrzędnego, który również został uruchomiony na platformie .NET 5.0 i uległ awarii. Awarie w kodzie natywnym nie spowodują wygenerowania zrzutu. Ta opcja działa w systemach Windows, macOS i Linux.

Zrzuty awaryjne w kodzie natywnym lub w przypadku korzystania z platformy .NET Core 3.1 lub starszej wersji można zbierać tylko w systemie Windows przy użyciu narzędzia Procdump. Katalog zawierający procdump.exe i procdump64.exe musi znajdować się w zmiennej środowiskowej PATH lub PROCDUMP_PATH. Pobierz narzędzia. Implikuje .--blame

Aby zebrać zrzut awaryjny z aplikacji natywnej uruchomionej na platformie .NET 5.0 lub nowszej, użycie narzędzia Procdump można wymusić przez ustawienie zmiennej środowiskowej VSTEST_DUMP_FORCEPROCDUMP na 1.
--blame-crash-dump-type <DUMP_TYPE> (Dostępne od zestawu .NET 5.0 SDK)

Typ zrzutu awaryjnego do zebrania. Obsługiwane typy zrzutów to full (wartość domyślna) i mini. Implikuje .--blame-crash
--blame-crash-collect-always (Dostępne od zestawu .NET 5.0 SDK)

Zbiera zrzut awaryjny przy oczekiwanym i nieoczekiwanym wyjściu hosta testowego.
--blame-hang (Dostępne od zestawu .NET 5.0 SDK)

Uruchom testy w trybie winy i zbiera zrzut zawieszenia, gdy test przekracza limit czasu.
--blame-hang-dump-type <DUMP_TYPE> (Dostępne od zestawu .NET 5.0 SDK)

Typ zrzutu awaryjnego do zebrania. Powinna to być fullwartość , minilub none. Gdy none zostanie określony, host testowy zostanie zakończony po przekroczeniu limitu czasu, ale nie zostanie zebrany zrzut. Implikuje .--blame-hang
--blame-hang-timeout <TIMESPAN> (Dostępne od zestawu .NET 5.0 SDK)

Limit czasu testu, po którym jest wyzwalany zrzut zawieszenia, a proces hosta testowego i wszystkie procesy podrzędne są po cenach dumpingowych i zakończonych. Wartość limitu czasu jest określona w jednym z następujących formatów:
- 1.5h, 1.5hour, 1.5hours
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400sec, 5400second, 5400seconds
- 5400000 ms, 54000000mil, 54000000 milisekund, 5400000 milisekund
Jeśli nie jest używana żadna jednostka (na przykład 54000000), przyjmuje się, że wartość jest wyrażona w milisekundach. W przypadku użycia razem z testami opartymi na danych zachowanie limitu czasu zależy od używanej karty testowej. Dla xUnit, NUnit. i MSTest 2.2.4+, limit czasu jest odnawiany po każdym przypadku testowym. W przypadku biblioteki MSTest przed wersją 2.2.4 limit czasu jest używany dla wszystkich przypadków testowych. Ta opcja jest obsługiwana w systemie Windows z netcoreapp2.1 systemem i nowszym w systemie Linux z systemem i nowszym netcoreapp3.1 oraz w systemie macOS z systemem lub nowszym net5.0 . 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 na potrzeby przebiegu testu. Aby uzyskać więcej informacji, zobacz Monitorowanie i analizowanie przebiegu testu.

Na przykład można zbierać pokrycie kodu przy użyciu --collect "Code Coverage" opcji . Aby uzyskać więcej informacji, zobacz Używanie pokrycia kodu, Dostosowywanie analizy pokrycia kodu i Problem z usługą GitHub dotnet/docs#34479.

Aby zebrać pokrycie kodu, możesz również użyć opcji Coverlet--collect "XPlat Code Coverage".
-d|--diag <LOG_FILE>

Włącza tryb diagnostyczny dla platformy testowej i zapisuje komunikaty diagnostyczne do określonego pliku i plików obok niego. Proces rejestrowania komunikatów określa, które pliki są tworzone, takie jak *.host_<date>.txt dziennik testowy hosta i *.datacollector_<date>.txt dziennik modułu zbierającego dane.
-e|--environment <NAME="VALUE">

Ustawia wartość zmiennej środowiskowej. Tworzy zmienną, jeśli nie istnieje, zastępuje ją, jeśli istnieje. Użycie tej opcji wymusi uruchomienie testów w izolowanym procesie. Tę opcję można określić wiele razy, aby udostępnić wiele zmiennych.
-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.
--filter <EXPRESSION>

Filtruje testy w bieżącym projekcie przy użyciu danego wyrażenia. Uruchamiane są tylko testy zgodne z wyrażeniem filtru. Aby uzyskać więcej informacji, zobacz sekcję Szczegóły opcji filtrowania. Aby uzyskać więcej informacji i przykładów dotyczących używania filtrowania selektywnego testu jednostkowego, zobacz Uruchamianie selektywnych testów jednostkowych.

-?|-h|--help

Wyświetla opis sposobu używania polecenia .

--interactive

Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania. Dostępny od wersji .NET Core 3.0 SDK.

-l|--logger <LOGGER>

Określa rejestrator wyników testu i opcjonalnie przełącza rejestratora. Określ ten parametr wiele razy, aby włączyć wiele rejestratorów. Aby uzyskać więcej informacji, zobacz Raportowanie wyników testów, Przełączniki dla rejestratorów i przykłady w dalszej części tego artykułu.

Aby przekazać przełączniki wiersza polecenia do rejestratora:
- Użyj pełnej nazwy przełącznika, a nie skróconej formy (na przykład verbosity zamiast v).
- Pomiń wszystkie wiodące kreski.
- Zastąp spację oddzielającą każdy przełącznik średnikiem ;.
- Jeśli przełącznik ma wartość, zastąp separator dwukropka między tym przełącznikiem a jego wartością znakiem =równości .
Na przykład -v:detailed --consoleLoggerParameters:ErrorsOnly stanie się .verbosity=detailed;consoleLoggerParameters=ErrorsOnly
--no-build

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

Uruchamianie testów bez wyświetlania baneru Microsoft TestPlatform. Dostępny 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ślona, domyślna ścieżka to ./bin/<configuration>/<framework>/. W przypadku projektów z wieloma platformami docelowymi (za pośrednictwem TargetFrameworks właściwości) należy również zdefiniować --framework podczas określania tej opcji. dotnet test zawsze uruchamia testy z katalogu wyjściowego. Możesz użyć polecenia , aby korzystać z AppDomain.BaseDirectory zasobów testowych w katalogu wyjściowym.
- Zestaw .NET 7.0.200 SDK lub nowszy
  
  Jeśli określisz opcję podczas uruchamiania --output tego polecenia w rozwiązaniu, interfejs wiersza polecenia będzie emitować ostrzeżenie (błąd w wersji 7.0.200) z powodu niejasnej semantyki ścieżki wyjściowej. Opcja --output jest niedozwolona, ponieważ wszystkie dane wyjściowe wszystkich projektów skompilowanych zostaną skopiowane do określonego katalogu, który nie jest zgodny z projektami wielokierunkowymi, a także projektami, które mają różne wersje zależności bezpośrednich i przechodnich. Aby uzyskać więcej informacji, zobacz Opcja na poziomie --output rozwiązania nie jest już prawidłowa dla poleceń związanych z kompilacją.

--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-x64wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . Dostępne od platformy .NET 6.

--results-directory <RESULTS_DIR>

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

Krótki formularz -r dostępny w wersjach zestawu .NET SDK starszych niż 7.
-r|--runtime <RUNTIME_IDENTIFIER>

Docelowe środowisko uruchomieniowe do przetestowania.

Krótki formularz -r dostępny począwszy od zestawu .NET SDK 7.
-s|--settings <SETTINGS_FILE>

Plik .runsettings do użycia do uruchamiania testów. Element TargetPlatform (x86|x64) nie ma wpływu na element dotnet test. Aby uruchomić testy przeznaczone dla platformy x86, zainstaluj wersję x86 platformy .NET Core. Bitowość dotnet.exe , która znajduje się na ścieżce, jest używana do uruchamiania testów. Aby uzyskać więcej informacji, zobacz następujące zasoby:
- Konfigurowanie testów jednostkowych przy użyciu .runsettings pliku.
- Konfigurowanie przebiegu testu
-t|--list-tests

Wyświetl listę odnalezionych testów zamiast uruchamiać testy.

-v|--verbosity <LEVEL>

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

args

Określa dodatkowe argumenty, które mają być przekazywane do karty. Użyj spacji, aby oddzielić wiele argumentów.

Lista możliwych argumentów zależy od określonego zachowania:
- W przypadku określenia projektu, rozwiązania lub katalogu albo pominięcia tego argumentu wywołanie jest przekazywane do msbuildelementu . W takim przypadku dostępne argumenty można znaleźć w dokumentacji dotnet msbuild.
- Po określeniu .dll lub .exe wywołanie jest przekazywane do vstest. W takim przypadku dostępne argumenty można znaleźć w dokumentacji dotnet vstest.
RunSettings Argumenty

Śródwierszowe RunSettings są przekazywane jako ostatnie argumenty w wierszu polecenia po ciągu "--" (zwróć uwagę na spację po --). RunSettings Wbudowane są określane jako [name]=[value] pary. Miejsce 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 Ustawienia za pośrednictwem wiersza polecenia.

Przykłady

Uruchom testy w projekcie w bieżącym katalogu:
```
dotnet test
```

Uruchom testy w projekcie test1 :

dotnet test ~/projects/test1/test1.csproj

Uruchom testy przy użyciu test1.dll zestawu:

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 system Windows):
```
dotnet test --collect "Code Coverage"
```
Uruchom testy w projekcie w bieżącym katalogu i zaloguj się ze szczegółową szczegółowością do konsoli:
```
dotnet test --logger "console;verbosity=detailed"
```
Uruchom testy w projekcie w bieżącym katalogu i zaloguj się przy użyciu rejestratora trx, aby przetestowaćResults.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 platformy docelowej w przypadku projektu wielokierunkowego. Dane wyjściowe dla każdej platformy 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 platformy docelowej.
Uruchom testy w projekcie w bieżącym katalogu i zaloguj się przy użyciu rejestratora trx do plików w folderze TestResults z nazwami plików unikatowymi dla każdej platformy docelowej:
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
Uruchom testy w projekcie w bieżącym katalogu i zaloguj się przy użyciu rejestratora html, aby testResults.html w 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 po awarii hosta testowego:
```
dotnet test --blame
```
Uruchom testy w projekcietest1, podając -bl argument (dziennika binarnego) na :msbuild
```
dotnet test ~/projects/test1/test1.csproj -bl
```
Uruchom testy w projekcie test1 , ustawiając właściwość MSBuild DefineConstants na DEV:
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
Uruchom testy w projekcie test1 , ustawiając właściwość MSBuild TestTfmsInParallel na false:
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--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:

Struktura testowa	Obsługiwane właściwości
MSTest	W pełniqualifiedName Nazwisko ClassName Priorytet TestCategory
xUnit	W pełniqualifiedName DisplayName Kategoria
NUnit	W pełniqualifiedName Nazwisko Kategoria Priorytet

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

Operator	Function
`=`	Dokładne dopasowanie
`!=`	Nie dokładne dopasowanie
`~`	Contains
`!~`	Nie zawiera

<value> jest ciągiem. Wszystkie wyszukiwania są bez uwzględniania wielkości liter.

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

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

Operator	Function
`\|`	LUB
`&`	ORAZ

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

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

dotnet test

Nazwisko

Streszczenie

opis

Niejawne przywracanie

Pobieranie manifestu obciążenia

Argumenty

Opcje

Przykłady

Szczegóły opcji filtrowania

Zobacz też

Opinia

Dodatkowe zasoby