dotnet test

Artikel
03/27/2024

Artikel ini berlaku untuk: ✔️ .NET Core 3.1 SDK dan versi yang lebih baru

Nama

dotnet test - uji coba .NET digunakan untuk menjalankan pengujian unit.

Sinopsis

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

Deskripsi

Perintah dotnet test digunakan untuk menjalankan pengujian unit dalam solusi tertentu. Perintah ini dotnet test membangun solusi dan menjalankan aplikasi host pengujian untuk setiap proyek pengujian dalam solusi menggunakan VSTest. Host pengujian menjalankan pengujian dalam proyek yang diberikan menggunakan kerangka pengujian, misalnya: MSTest, NUnit, atau xUnit, dan melaporkan keberhasilan atau kegagalan setiap pengujian. Jika semua pengujian berhasil, runner pengujian menampilkan 0 sebagai kode keluar; atau, jika ada pengujian yang gagal, akan menampilkan 1.

Catatan

dotnet test awalnya dirancang untuk hanya VSTestmendukung proyek pengujian berbasis. Versi terbaru kerangka kerja pengujian menambahkan dukungan untuk Microsoft.Testing.Platform. Platform pengujian alternatif ini lebih ringan dan lebih cepat daripada VSTest dan mendukung dotnet test dengan opsi baris perintah yang berbeda. Untuk informasi selengkapnya, lihat Microsoft.Testing.Platform.

Untuk proyek multi-target, pengujian dijalankan untuk setiap kerangka kerja yang ditargetkan. Host pengujian dan kerangka kerja pengujian unit dikemas sebagai paket NuGet dan dipulihkan sebagai dependensi biasa untuk proyek. Dimulai dengan .NET 9 SDK, pengujian ini dijalankan secara paralel secara default. Untuk menonaktifkan eksekusi paralel, atur TestTfmsInParallel properti MSBuild ke false. Untuk informasi selengkapnya, lihat Menjalankan pengujian secara paralel dan contoh baris perintah nanti di artikel ini.

Proyek pengujian menentukan runner pengujian menggunakan elemen <PackageReference> biasa, seperti yang terlihat dalam file proyek sampel berikut:

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

  <PropertyGroup>
    <TargetFramework>net6.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>

Di mana Microsoft.NET.Test.Sdk adalah host uji, xunit adalah kerangka kerja pengujian. Dan xunit.runner.visualstudio adalah adapter pengujian, yang memungkinkan kerangka kerja xUnit bekerja dengan host pengujian.

Pemulihan implisit

Anda tidak harus menjalankan dotnet restore karena dijalankan secara implisit oleh semua perintah yang memerlukan terjadinya pemulihan, seperti dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish, dan dotnet pack. Untuk menonaktifkan pemulihan implisit, gunakan opsi --no-restore.

Perintah dotnet restore masih berguna dalam skenario tertentu di mana pemulihan secara eksplisit masuk akal, seperti pembangunan integrasi berkelanjutan di Azure DevOps Services atau dalam sistem pembangunan yang perlu secara eksplisit mengontrol saat pemulihan terjadi.

Untuk informasi tentang cara mengelola umpan NuGet, lihat dotnet restore dokumentasi.

Pengunduhan manifes beban kerja

Saat Anda menjalankan perintah ini, pengunduhan latar belakang asinkron manifes iklan untuk beban kerja akan dimulai. Jika unduhan masih berjalan saat perintah ini selesai, unduhan akan dihentikan. Untuk informasi selengkapnya, lihat Manifes iklan.

Argumen

PROJECT | SOLUTION | DIRECTORY | DLL | EXE
- Jalur ke proyek pengujian.
- Jalan menuju solusi.
- Jalur ke direktori yang berisi proyek atau solusi.
- Jalur ke file .dll proyek pengujian.
- Jalur ke file .exe proyek pengujian.
Jika tidak ditentukan, efeknya sama dengan menggunakan argumen DIRECTORY untuk menentukan direktori saat ini.

Opsi

Peringatan

Melanggar perubahan dalam opsi:

Mulai dari .NET 7: beralih -a ke alias --arch alih-alih --test-adapter-path
Mulai dari .NET 7: beralih -r ke alias --runtime alih-alih --results-directory

Peringatan

Saat menggunakan Microsoft.Testing.Platform, silakan lihat integrasi pengujian dotnet untuk opsi yang didukung. Sebagai aturan praktis, setiap opsi yang tidak terkait dengan pengujian didukung sementara setiap opsi terkait pengujian tidak didukung apa adanya.

--test-adapter-path <ADAPTER_PATH>

Jalur ke direktori yang akan dicari untuk adapter pengujian tambahan. Hanya file .dll dengan akhiran .TestAdapter.dll yang diperiksa. Jika tidak ditentukan, direktori .dll pengujian akan dicari.

Formulir -a pendek tersedia dalam versi .NET SDK yang lebih lama dari 7.

--arch <ARCHITECTURE>

Menentukan arsitektur target. Hal ini adalah sintaks singkat untuk mengatur Pengidentifikasi Runtime (RID), di mana nilai yang disediakan digabung dengan RID default. Misalnya, pada komputer win-x64, menentukan --arch x86 akan mengatur RID ke win-x86. Jika Anda menggunakan opsi ini, jangan gunakan opsi -r|--runtime. Tersedia sejak .NET 6 Preview 7.

--artifacts-path <ARTIFACTS_DIR>

Semua file output build dari perintah yang dijalankan akan masuk ke subfolder di bawah jalur yang ditentukan, dipisahkan oleh proyek. Untuk informasi selengkapnya, lihat Tata Letak Output Artefak. Tersedia sejak .NET 8 SDK.

--blame

Menjalankan tes dalam mode menyalahkan. Opsi ini sangat membantu dalam mengisolasi pengujian bermasalah yang menyebabkan host pengujian crash. Ketika crash terdeteksi, opsi ini membuat file urutan di TestResults/<Guid>/<Guid>_Sequence.xml yang menangkap urutan pengujian yang dijalankan sebelum crash.

Opsi ini tidak membuat cadangan memori dan tidak membantu ketika pengujian menggantung.
--blame-crash (Tersedia sejak SDK .NET 5.0)

Menjalankan pengujian dalam mode pengubahan dan mengumpulkan crash dump ketika host pengujian keluar secara tak terduga. Opsi ini bergantung pada versi .NET yang digunakan, jenis kesalahan, dan sistem operasi.

Untuk pengecualian dalam kode terkendali, crash dump akan dikumpulkan secara otomatis pada .NET 5.0 dan versi yang lebih baru. Hal ini akan menghasilkan crash dump untuk host pengujian atau proses turunan apa pun yang juga berjalan di .NET 5.0 dan crash. Crash dalam kode native tidak akan menghasilkan crash dump. Opsi ini berfungsi di Windows, macOS, dan Linux.

Crash dump dalam kode native, atau saat menggunakan .NET Core 3.1 atau versi sebelumnya, hanya dapat dikumpulkan di Windows, menggunakan Procdump. Direktori yang berisi procdump.exe dan procdump64.exe harus berada dalam variabel lingkungan PATH atau PROCDUMP_PATH. Unduh alatnya. Menyiratkan --blame.

Untuk mengumpulkan crash dump dari aplikasi native yang berjalan pada .NET 5.0 atau yang lebih baru, penggunaan Procdump dapat dipaksa dengan mengatur variabel lingkungan VSTEST_DUMP_FORCEPROCDUMP ke 1.
--blame-crash-dump-type <DUMP_TYPE> (Tersedia sejak SDK .NET 5.0)

Jenis crash dump yang akan dikumpulkan. Jenis cadangan yang didukung adalah full (default), dan mini. Menyiratkan --blame-crash.
--blame-crash-collect-always (Tersedia sejak SDK .NET 5.0)

Mengumpulkan crash dump pada proses keluar host pengujian yang diharapkan serta yang tak terduga.
--blame-hang (Tersedia sejak SDK .NET 5.0)

Jalankan pengujian dalam mode pengubahan dan kumpulkan crash dump hang ketika pengujian melebihi batas waktu yang diberikan.
--blame-hang-dump-type <DUMP_TYPE> (Tersedia sejak SDK .NET 5.0)

Jenis crash dump yang akan dikumpulkan. Ini seharusnya berupa full, mini, atau none. Saat none ditentukan, host pengujian dihentikan pada batas waktu, tetapi tidak ada crash dump yang dikumpulkan. Menyiratkan --blame-hang.
--blame-hang-timeout <TIMESPAN> (Tersedia sejak SDK .NET 5.0)

Batas waktu per-pengujian, setelah itu crash dump hang dipicu dan proses host pengujian dan semua proses turunannya dibuang dan dihentikan. Nilai batas waktu ditentukan dalam salah satu format berikut:
- 1.5h, 1.5hour, 1.5hours
- 90m, 90min, 90minute, 90minutes
- 5400s, 5400sec, 5400second, 5400seconds
- 5400000ms, 5400000mil, 5400000millisecond, 5400000milliseconds
Saat tidak ada unit yang digunakan (misalnya, 5400000), nilai diasumsikan dalam milidetik. Saat digunakan bersama dengan pengujian berbasis data, perilaku batas waktu akan bergantung pada adapter pengujian yang digunakan. Untuk xUnit, NUnit. dan MSTest 2.2.4+, batas waktu diperpanjang setelah setiap kasus pengujian. Untuk MSTest sebelum versi 2.2.4, batas waktu digunakan untuk semua kasus pengujian. Opsi ini didukung pada Windows dengan netcoreapp2.1 dan yang lebih baru, di Linux dengan netcoreapp3.1 dan yang lebih baru, dan di macOS dengan net5.0 atau yang lebih baru. Menyiratkan --blame dan --blame-hang.

-c|--configuration <CONFIGURATION>

Menentukan konfigurasi build. Pengaturan default untuk sebagian besar proyek adalah Debug, tetapi Anda dapat mengambil alih pengaturan konfigurasi build di proyek Anda.

--collect <DATA_COLLECTOR_NAME>

Mengaktifkan pengumpul data untuk eksekusi pengujian. Untuk informasi selengkapnya, lihat Memantau dan menganalisis pengujian.

Misalnya Anda dapat mengumpulkan cakupan kode dengan menggunakan --collect "Code Coverage" opsi . Untuk informasi selengkapnya, lihat Menggunakan cakupan kode, Menyesuaikan analisis cakupan kode, dan masalah GitHub dotnet/docs#34479.

Untuk mengumpulkan cakupan kode, Anda juga dapat menggunakan Coverlet dengan menggunakan --collect "XPlat Code Coverage" opsi .
-d|--diag <LOG_FILE>

Mengaktifkan mode diagnostik untuk platform pengujian dan menulis pesan diagnostik ke file yang ditentukan dan ke file di sebelahnya. Proses yang membuat log pada pesan menentukan file mana yang dibuat, seperti *.host_<date>.txt untuk log host pengujian, dan *.datacollector_<date>.txt untuk log pengumpul data.
-e|--environment <NAME="VALUE">

Mengatur nilai variabel lingkungan. Membuat variabel jika tidak ada, ambil alih jika memang ada. Penggunaan opsi ini akan memaksa pengujian dijalankan dalam proses yang terisolasi. Opsi dapat ditentukan beberapa kali untuk menyediakan beberapa variabel.
-f|--framework <FRAMEWORK>

Moniker kerangka kerja target (TFM) dari kerangka kerja target untuk menjalankan pengujian. Kerangka kerja target juga harus ditentukan dalam file proyek.
--filter <EXPRESSION>

Memfilter pengujian dalam proyek saat ini menggunakan ekspresi yang diberikan. Hanya pengujian yang cocok dengan ekspresi filter yang dijalankan. Untuk informasi selengkapnya, lihat bagian Detail opsi filter. Untuk informasi dan contoh selengkapnya tentang cara menggunakan pemfilteran pengujian unit selektif, lihat Menjalankan pengujian unit selektif.

-?|-h|--help

Mencetak deskripsi cara menggunakan perintah.

--interactive

Memungkinkan perintah berhenti dan menunggu input atau tindakan pengguna. Misalnya, untuk menyelesaikan autentikasi. Tersedia sejak SDK .NET Core 3.0.

-l|--logger <LOGGER>

Menentukan pencatat untuk hasil pengujian dan secara opsional beralih untuk pencatat. Tentukan parameter ini beberapa kali untuk mengaktifkan beberapa pencatat. Untuk informasi selengkapnya, lihat Melaporkan hasil pengujian, Beralih untuk pencatat, dan contohnya nanti di artikel ini.

Untuk meneruskan sakelar baris perintah ke pencatat:
- Gunakan nama lengkap sakelar, bukan formulir yang disingkat (misalnya, verbosity bukan v).
- Hilangkan tanda hubung di awal.
- Ganti spasi yang memisahkan setiap sakelar dengan titik koma ;.
- Jika sakelar memiliki nilai, ganti pemisah titik dua antara sakelar tersebut dan nilainya dengan tanda =sama dengan .
Misalnya, -v:detailed --consoleLoggerParameters:ErrorsOnly akan menjadi verbosity=detailed;consoleLoggerParameters=ErrorsOnly.
--no-build

Tidak membangun proyek pengujian sebelum menjalankannya. Ini juga secara implisit --no-restore mengatur bendera.
--nologo

Jalankan pengujian tanpa menampilkan banner Microsoft TestPlatform. Tersedia sejak SDK .NET Core 3.0.
--no-restore

Tidak menjalankan pemulihan implisit saat menjalankan perintah.
-o|--output <OUTPUT_DIRECTORY>

Direktori untuk menemukan binari untuk dijalankan. Jika tidak ditentukan, nilai default-nya adalah ./bin/<configuration>/<framework>/. Untuk proyek dengan beberapa kerangka kerja target (melalui properti TargetFrameworks), Anda juga perlu menentukan --framework saat Anda menentukan opsi ini. dotnet test selalu menjalankan pengujian dari direktori output. Anda dapat menggunakan AppDomain.BaseDirectory untuk menggunakan aset pengujian di direktori output.
- .NET 7.0.200 SDK dan yang lebih baru
  
  Jika Anda menentukan --output opsi saat menjalankan perintah ini pada solusi, CLI akan mengeluarkan peringatan (kesalahan dalam 7.0.200) karena semantik jalur output yang tidak jelas. Opsi --output ini tidak diizinkan karena semua output dari semua proyek yang dibuat akan disalin ke direktori yang ditentukan, yang tidak kompatibel dengan proyek multi-target, serta proyek yang memiliki versi dependensi langsung dan transitif yang berbeda. Untuk informasi selengkapnya, lihat Opsi tingkat solusi --output tidak lagi valid untuk perintah terkait build.

--os <OS>

Menentukan sistem operasi (OS) target. Hal ini adalah sintaks singkat untuk mengatur Pengidentifikasi Runtime (RID), di mana nilai yang disediakan digabung dengan RID default. Misalnya, pada komputer win-x64, menentukan --os linux akan mengatur RID ke linux-x64. Jika Anda menggunakan opsi ini, jangan gunakan opsi -r|--runtime. Tersedia sejak .NET 6.

--results-directory <RESULTS_DIR>

Direktori tempat hasil pengujian akan ditempatkan. Jika tidak ada, direktori yang ditentukan akan dibuat. Defaultnya ada TestResults di direktori yang berisi file proyek.

Formulir -r pendek tersedia dalam versi .NET SDK yang lebih lama dari 7.
-r|--runtime <RUNTIME_IDENTIFIER>

Runtime bahasa umum target yang akan diuji.

Formulir -r pendek tersedia mulai dari .NET SDK 7.
-s|--settings <SETTINGS_FILE>

File .runsettings yang digunakan untuk menjalankan pengujian. Elemen TargetPlatform (x86|x64) tidak berpengaruh untuk dotnet test. Untuk menjalankan pengujian yang menargetkan x86, instal versi x86 .NET Core. Bitness dari dotnet.exe yang ada di jalur adalah yang akan digunakan untuk menjalankan pengujian. Untuk informasi selengkapnya, lihat sumber daya berikut:
- Mengonfigurasi pengujian unit dengan menggunakan file .runsettings.
- Mengonfigurasi uji coba
-t|--list-tests

Buat daftar pengujian yang ditemukan, bukan menjalankan pengujian.

-v|--verbosity <LEVEL>

Mengatur tingkat verbositas perintah. Nilai yang diizinkan adalah q[uiet], m[inimal], n[ormal], d[etailed], dan diag[nostic]. Default adalah minimal. Untuk informasi selengkapnya, lihat LoggerVerbosity .

args

Menentukan argumen tambahan untuk diteruskan ke adapter. Gunakan spasi untuk memisahkan beberapa argumen.

Daftar argumen yang mungkin bergantung pada perilaku yang ditentukan:
- Saat menentukan proyek, solusi, atau direktori, atau jika Anda menghilangkan argumen ini, panggilan akan diteruskan ke msbuild. Dalam hal ini, argumen yang tersedia dapat ditemukan dalam dokumentasi msbuild dotnet.
- Saat Anda menentukan .dll atau .exe, panggilan akan diteruskan ke vstest. Dalam hal ini, argumen yang tersedia dapat ditemukan di dokumentasi vstest dotnet.
Argumen RunSettings

RunSettings sebaris diteruskan sebagai argumen terakhir pada baris perintah setelah "-- " (perhatikan spasi setelah --). RunSettings sebaris ditentukan sebagai pasangan [name]=[value]. Spasi digunakan untuk memisahkan beberapa pasangan [name]=[value].

Contoh: dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True

Untuk informasi selengkapnya, lihat Meneruskan argumen RunSettings melalui baris perintah.

Contoh

Jalankan pengujian dalam proyek di direktori saat ini:
```
dotnet test
```

Jalankan pengujian dalam proyek test1:

dotnet test ~/projects/test1/test1.csproj

Jalankan pengujian menggunakan assembly test1.dll:

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

Jalankan pengujian dalam proyek di direktori saat ini, dan hasilkan file hasil pengujian dalam format trx:
```
dotnet test --logger trx
```
Jalankan pengujian dalam proyek di direktori saat ini, dan buat file cakupan kode (setelah menginstal integrasi pengumpul Coverlet):
```
dotnet test --collect:"XPlat Code Coverage"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan buat file cakupan kode (hanya Windows):
```
dotnet test --collect "Code Coverage"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan catat dengan verbositas mendetail ke konsol:
```
dotnet test --logger "console;verbosity=detailed"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan catat dengan pencatat trx ke testResults.trx di folder TestResults:
```
dotnet test --logger "trx;logfilename=testResults.trx"
```
Karena nama file log ditentukan, nama yang sama akan digunakan untuk setiap kerangka kerja target dalam kasus proyek multi-target. Output untuk setiap kerangka kerja target menimpa output untuk kerangka kerja target sebelumnya. File dibuat di folder TestResults di folder proyek pengujian, karena jalur relatif bersifat relatif terhadap folder tersebut. Contoh berikut menunjukkan cara membuat file terpisah untuk setiap kerangka kerja target.
Jalankan pengujian dalam proyek di direktori saat ini, dan catat dengan pencatat trx ke file di folder TestResults, dengan nama file yang unik untuk setiap kerangka kerja target:
```
dotnet test --logger:"trx;LogFilePrefix=testResults"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan catat dengan pencatat trx ke testResults.trx di folder TestResults:
```
dotnet test --logger "html;logfilename=testResults.html"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan laporkan pengujian yang sedang berlangsung saat host pengujian mengalami crash:
```
dotnet test --blame
```
Jalankan pengujian dalam proyek test1, yang menyediakan argumen -bl (log biner) ke msbuild:
```
dotnet test ~/projects/test1/test1.csproj -bl
```
Jalankan pengujian dalam proyek test1, yang mengatur properti DefineConstants MSBuild ke DEV:
```
dotnet test ~/projects/test1/test1.csproj -p:DefineConstants="DEV"
```
Jalankan pengujian dalam proyek test1, yang mengatur properti TestTfmsInParallel MSBuild ke false:
```
dotnet test ~/projects/test1/test1.csproj -p:TestTfmsInParallel=false
```

--filter <EXPRESSION>

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

<property> adalah atribut dari Test Case. Berikut adalah properti yang didukung oleh kerangka kerja pengujian unit populer:

Kerangka Kerja Pengujian	Properti yang didukung
MSTest	FullyQualifiedName Nama ClassName Prioritas TestCategory
xUnit	FullyQualifiedName DisplayName Kategori
NUnit	FullyQualifiedName Nama Kategori Prioritas

<operator> menjelaskan hubungan antara properti dan nilai:

Operator	Fungsi
`=`	Sama persis
`!=`	Tidak sama persis
`~`	Berisi
`!~`	Tak berisi

<value> adalah string. Semua pencarian tidak peka huruf besar/kecil.

Ekspresi tanpa <operator> secara otomatis dianggap sebagai contains pada properti FullyQualifiedName (misalnya, dotnet test --filter xyz sama dengan dotnet test --filter FullyQualifiedName~xyz).

Ekspresi dapat digabungkan dengan operator kondisional:

Operator	Fungsi
`\|`	ATAU
`&`	AND

Anda dapat menyertakan ekspresi dalam tanda kurung saat menggunakan operator kondisional (misalnya (Name~TestMethod1) | (Name~TestMethod2)).

Untuk informasi dan contoh selengkapnya tentang cara menggunakan pemfilteran pengujian unit selektif, lihat Menjalankan pengujian unit selektif.

Bagikan melalui