uji dotnet dengan VSTest

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

Nama

dotnet test - .NET test driver yang digunakan untuk menjalankan pengujian unit dengan VSTest.

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>]
    [--disable-build-servers]
    [-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]
    [--tl:[auto|on|off]]
    [-v|--verbosity <LEVEL>]
    [<args>...]
    [[--] <RunSettings arguments>]

dotnet test -h|--help

Description

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.

Nota

dotnet test awalnya dirancang untuk hanya VSTestmendukung proyek pengujian berbasis. Versi terbaru kerangka kerja pengujian menambahkan dukungan untuk Microsoft. Testing.Platform (MTP). 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 pengujian dotnet dengan MTP.

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

Di mana Microsoft.NET.Test.Sdk adalah host pengujian, 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 build integrasi berkelanjutan di Azure DevOps Services atau dalam sistem build yang perlu mengontrol secara eksplisit ketika 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.

Arguments

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

--test-adapter-path <ADAPTER_PATH>

Jalur ke adaptor kustom yang akan digunakan untuk uji coba.

Formulir pendek -a tersedia dalam versi SDK .NET yang lebih lama dari 7.
-a|--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 Pratinjau 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 . Opsi ini dan nilai yang disediakan harus secara eksplisit dikaitkan dalam perintah apa pun dotnet yang bergantung pada output perintah lain dotnet , misalnya, saat menggunakan dotnet build --no-restore dan dotnet publish --no-build. 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 saat pengujian menggantung.
--blame-crash (Tersedia sejak .NET 5.0 SDK)

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

Untuk pengecualian dalam kode terkelola, cadangan akan dikumpulkan secara otomatis pada .NET 5.0 dan versi yang lebih baru. Ini akan menghasilkan cadangan untuk testhost atau proses anak apa pun yang juga berjalan pada .NET 5.0 dan crash. Crash dalam kode native tidak akan menghasilkan crash dump. Opsi ini berfungsi pada Windows, macOS, dan Linux.

Crash dump dalam kode asli, atau saat menggunakan .NET Core 3.1 atau versi yang lebih lama, hanya dapat dikumpulkan pada Windows, dengan 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 asli yang berjalan pada .NET 5.0 atau yang lebih baru, penggunaan Procdump dapat dipaksa dengan mengatur variabel lingkungan VSTEST_DUMP_FORCEPROCDUMP ke 1.

Untuk daftar lengkap variabel lingkungan platform pengujian, lihat Variabel lingkungan.
--blame-crash-dump-type <DUMP_TYPE> (Tersedia sejak .NET 5.0 SDK)

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

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

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 .NET 5.0 SDK)

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 .NET 5.0 SDK)

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, 90 menit, 90 menit, 90 menit
5400s, 5400sec, 5400 detik, 5400 detik
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.

Anda juga dapat mengonfigurasi kesalahan dalam .runsettings file dan meneruskannya dengan --settings. File .runsettings mendukung perilaku menyalahkan yang sama dan kunci tambahan yang tidak diekspos sebagai sakelar tingkat dotnet test atas, seperti CollectDumpOnTestSessionHang dan MonitorPostmortemDebugger. Untuk informasi selengkapnya, lihat Menyalahkan pengumpul data.

<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="blame" enabled="true">
        <Configuration>
          <CollectDump CollectAlways="true" DumpType="full" />
          <CollectDumpOnTestSessionHang TestTimeout="30min" HangDumpType="full" />
          <MonitorPostmortemDebugger DumpDirectoryPath="C:\Dumps" />
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

Tabel berikut memetakan opsi menyalahkan ke sakelar dan .runsettings elemennyadotnet test. Untuk referensi kolektor kesalahan lengkap, lihat Menyalahkan pengumpul data.

Opsi crash dump:

Behavior	`dotnet test` sakelar	`.runsettings` elemen
Mengumpulkan crash dump	`--blame-crash`	`<CollectDump />`
Kumpulkan bahkan pada pintu keluar yang bersih	`--blame-crash-collect-always`	`<CollectDump CollectAlways="true" />`
Jenis cadangan (`mini`, `full`; default `full`)	`--blame-crash-dump-type`	`<CollectDump DumpType="full" />`

Opsi hang dump:

Behavior	`dotnet test` Beralih	`.runsettings` elemen
Mengumpulkan hang dump	`--blame-hang`	`<CollectDumpOnTestSessionHang />`
Waktu habis sebelum hang dump (default `1h`)	`--blame-hang-timeout`	`<CollectDumpOnTestSessionHang TestTimeout="90m" />`
Jenis hang dump (`mini`, `full`, `none`)	`--blame-hang-dump-type`	`<CollectDumpOnTestSessionHang HangDumpType="mini" />`

Untuk Microsoft. Aplikasi pengujian Testing.Platform (MTP), sakelar, --blame-* dan pengumpul data yang disalahkan tidak berlaku. MTP menggunakan --crashdump, --hangdump, dan --hangdump-timeout dari Microsoft.Testing.Extensions.CrashDump paket dan Microsoft.Testing.Extensions.HangDump . Untuk informasi selengkapnya, lihat pengujian dotnet dengan MTP.

-c|--configuration <CONFIGURATION>

Menentukan konfigurasi build. 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, termasuk pengumpul data Log Peristiwa dan panduan untuk menulis pengumpul data Anda sendiri, lihat Memantau dan menganalisis eksekusi pengujian.

Misalnya Anda dapat mengumpulkan cakupan kode dengan menggunakan --collect "Code Coverage" opsi . Untuk informasi selengkapnya, lihat Gunakan cakupan kode, Stomisasi analisis cakupan kode, dan GitHub menerbitkan 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.

Untuk mengatur tingkat pelacakan, tambahkan ;tracelevel=<LEVEL> ke nama file log, misalnya --diag log.txt;tracelevel=verbose. Nilai yang diizinkan untuk tracelevel adalah off, , errorwarning, info, dan verbose. Nilai defaultnya adalah verbose.
--disable-build-servers

Memaksa perintah untuk mengabaikan server build persisten apa pun. Opsi ini menyediakan cara yang konsisten untuk menonaktifkan semua penggunaan penembolokan build, yang memaksa build dari awal. Build yang tidak mengandalkan cache berguna ketika cache mungkin rusak atau salah karena beberapa alasan. Tersedia sejak .NET 7 SDK.
-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.
-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 mengatur bendera --no-restore.
--nologo

Jalankan pengujian tanpa menampilkan banner testPlatform Microsoft. Tersedia sejak .NET Core 3.0 SDK.
--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 opsi --output saat menjalankan perintah ini pada solusi, CLI akan mengeluarkan peringatan (kesalahan dalam 7.0.200) karena semantik jalur output yang tidak jelas. Opsi --output 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 --output tingkat solusi 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 direktori yang ditentukan tidak ada, direktori tersebut akan dibuat. Defaultnya ada TestResults di direktori yang berisi file proyek.

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

Runtime bahasa umum target yang akan diuji.

Formulir pendek -r tersedia mulai .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 ini:
- Mengonfigurasi pengujian unit dengan menggunakan file .runsettings.
- Mengonfigurasi sebuah uji coba
-t|--list-tests

Buat daftar pengujian yang ditemukan, bukan menjalankan pengujian.
--tl:[auto|on|off]

Menentukan apakah Terminal Logger harus digunakan untuk output build. Defaultnya adalah auto, yang pertama memverifikasi lingkungan sebelum mengaktifkan pengelogan terminal. Pemeriksaan lingkungan memverifikasi bahwa terminal mampu menggunakan fitur output modern dan tidak menggunakan output standar yang dialihkan sebelum mengaktifkan pencatat baru. on melewati pemeriksaan lingkungan dan mengaktifkan pengelogan terminal. off melewati pemeriksaan lingkungan dan menggunakan pencatat konsol default.

Terminal Logger menunjukkan fase pemulihan diikuti oleh fase build. Selama setiap fase, proyek bangunan saat ini muncul di bagian bawah terminal. Setiap proyek yang membangun menghasilkan target MSBuild yang saat ini sedang dibangun dan jumlah waktu yang dihabiskan untuk target tersebut. Anda dapat mencari informasi ini untuk mempelajari lebih lanjut tentang build. Setelah proyek selesai dibangun, satu bagian "build completed" ditulis yang menangkap:
- Nama proyek bawaan.
- Kerangka kerja target (jika multi-target).
- Status build tersebut.
- Output utama build tersebut (yang di-hyperlink).
- Diagnostik apa pun yang dihasilkan untuk proyek tersebut.
Opsi ini tersedia mulai dari .NET 8.
-v|--verbosity <LEVEL>

Mengatur tingkat verbositas perintah. Nilai yang diizinkan adalah q[uiet], m[inimal], n[ormal], d[etailed], dan diag[nostic]. Defaultnya 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

Dimulai dengan .NET 5 SDK, Anda juga dapat mengatur TestRunParameters dari baris perintah, misalnya: dotnet test -- TestRunParameters.Parameter(name="myParam", value="value"). RunSettings argumen lebih diutamakan daripada nilai dari .runsettings file.

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

Examples

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 menggunakan Microsoft Cakupan Kode:
```
dotnet test --collect "Code Coverage"
```
Jalankan pengujian dalam proyek di direktori saat ini, dan buat file cakupan kode menggunakan Coverlet (setelah menginstal integrasi Coverlet kolektor):
```
dotnet test --collect:"XPlat 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 Priority TestCategory
xUnit	FullyQualifiedName NamaTampilan Sifat
NUnit	FullyQualifiedName Nama Priority TestCategory Kategori Property

Untuk xUnit, sifat yang ditentukan dengan [Trait("key", "value")] difilter oleh kuncinya (misalnya, [Trait("Category", "bvt")] dicocokkan dengan --filter Category=bvt). Untuk NUnit, TestCategory dan Category setara, dan properti yang ditentukan dengan [Property("key", "value")] difilter oleh kuncinya.

<operator> menjelaskan hubungan antara properti dan nilai:

Operator	Function
`=`	Kecocokan 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	Function
`\|`	OR
`&`	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.

Kode keluaran

Saat Anda menjalankan pengujian melalui jalur VSTest, dotnet test laporkan hasilnya dengan salah satu dari dua kode keluar:

Kode keluar	Meaning
`0`	Sukses. Operasi yang diminta selesai dan, untuk uji coba, semua pengujian yang dijalankan lulus.
`1`	Kegagalan. Misalnya, satu atau beberapa pengujian gagal, kesalahan eksekusi dilaporkan, baris perintah tidak valid, sumber pengujian tidak dapat dimuat, atau eksekusi dibatalkan atau dibatalkan.

Proses yang mendasar vstest.console tidak pernah mengembalikan nilai lain.

Ketika penemuan tidak menemukan pengujian yang cocok, eksekusi mencetak peringatan daripada kesalahan dan masih kembali 0 secara default. Untuk membuat eksekusi yang menemukan atau memilih nol pengujian yang dikembalikan 1 , atur RunConfiguration.TreatNoTestsAsError ke true dalam .runsettings file.

Lihat juga

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-07-27