dotnet test
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>]
[--artifacts-path <ARTIFACTS_DIR>]
[--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 przy użyciu polecenia VSTest
. 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.
Uwaga
dotnet test
pierwotnie został zaprojektowany tak, aby obsługiwał tylko VSTest
projekty testowe oparte na platformie . Najnowsze wersje platform testowych dodają obsługę biblioteki Microsoft.Testing.Platform. Ta alternatywna platforma testowa jest bardziej uproszczona i szybsza niż VSTest
i obsługiwana dotnet test
przy użyciu różnych opcji wiersza polecenia. Aby uzyskać więcej informacji, zobacz Microsoft.Testing.Platform.
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>net8.0</TargetFramework>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.10.0" />
<PackageReference Include="xunit" Version="2.8.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.8.1" />
</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 run
dotnet 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
Ostrzeżenie
W przypadku korzystania z programu Microsoft.Testing.Platform
zapoznaj się z integracją testu dotnet, aby zapoznać się z obsługiwanymi opcjami. Zgodnie z regułą kciuka każda opcja niezwiązana z testowaniem jest obsługiwana, podczas gdy każda opcja związana z testowaniem nie jest obsługiwana.
--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 nawin-x86
wartość . Jeśli używasz tej opcji, nie używaj-r|--runtime
opcji . Dostępne od wersji zapoznawczej 7 platformy .NET 6.
--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 (Układ danych wyjściowych artefaktów). Dostępne od zestawu .NET 8 SDK.
--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
na1
.--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) imini
. 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ć
full
wartość ,mini
lubnone
. Gdynone
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 nowszymnetcoreapp3.1
oraz w systemie macOS z systemem lub nowszymnet5.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
zamiastv
). - 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 .
Przykładowo,
-v:detailed --consoleLoggerParameters:ErrorsOnly
stanie sięverbosity=detailed;consoleLoggerParameters=ErrorsOnly
.- Użyj pełnej nazwy przełącznika, a nie skróconej formy (na przykład
--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średnictwemTargetFrameworks
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 nalinux-x64
wartość . 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. ElementTargetPlatform
(x86|x64) nie ma wpływu na elementdotnet 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:-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]
, idiag[nostic]
. Wartość domyślna tominimal
. 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
msbuild
elementu . 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.
- W przypadku określenia projektu, rozwiązania lub katalogu albo pominięcia tego argumentu wywołanie jest przekazywane do
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 RunSettings 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 projekcie
test1
, 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ść MSBuildDefineConstants
naDEV
:dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
Uruchom testy w projekcie
test1
, ustawiając właściwość MSBuildTestTfmsInParallel
nafalse
:dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
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:
Struktura testowa | Obsługiwane właściwości |
---|---|
MSTest |
|
xUnit |
|
NUnit |
|
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.