Migrasi dari VSTest ke Microsoft. Testing.Platform (MTP)

Dalam artikel ini, Anda mempelajari cara bermigrasi dari VSTest ke MTP.

Artikel ini berfokus pada langkah-langkah migrasi dan pemetaan argumen.

Jika Anda masih perlu memilih platform, mulailah dengan Gambaran umum platform Pengujian.

Jika Anda memerlukan perilaku dotnet test mode terperinci, lihat Pengujian dengan dotnet test.

Jika Anda memerlukan satu daftar opsi baris perintah platform dan ekstensi, lihat referensi opsi MTP CLI.

Pilih untuk bergabung menggunakan MTP

Langkah pertama dalam migrasi adalah memilih untuk menggunakan MTP.

Untuk semua kerangka kerja pengujian, tambahkan <OutputType>Exe</OutputType> ke semua proyek pengujian dalam solusi. Setelah itu, ikuti panduan khusus kerangka kerja.

MSTest

MTP didukung oleh MSTest mulai dari 3.2.0. Namun, sebaiknya perbarui ke versi MSTest terbaru yang tersedia.

Untuk ikut serta, tambahkan <EnableMSTestRunner>true</EnableMSTestRunner> di bawah PropertyGroup di file Directory.Build.props.

Nota

Saat menggunakan MSTest.Sdk, MTP digunakan secara default, kecuali <UseVSTest>true</UseVSTest> ditentukan.

NUnit

MTP didukung oleh NUnit3TestAdapter mulai dari 5.0.0.

Untuk ikut serta, tambahkan <EnableNUnitRunner>true</EnableNUnitRunner> di bawah PropertyGroup di file Directory.Build.props.

xUnit.net

MTP didukung mulai dari xunit.v3.

Untuk ikut serta, tambahkan <UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner> di bawah PropertyGroup di file Directory.Build.props.

dotnet test

Pilihan untuk .NET 9 SDK dan versi sebelumnya

Dalam .NET 9 SDK dan versi sebelumnya, tidak ada dukungan bawaan untuk MTP untuk dotnet test. Dukungan dibangun di atas infrastruktur VSTest. Untuk menggunakannya, tambahkan <TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport> di bawah PropertyGroup dalam file Directory.Build.props.

Penting

Saat menjalankan dukungan MTP dalam mode ini, Anda perlu menambahkan -- untuk memisahkan dotnet test argumen dari argumen platform baru. Contohnya, dotnet test --no-build -- --list-tests.

Ikut serta untuk .NET 10 SDK dan yang lebih baru

Dimulai dengan .NET 10 SDK, ada dukungan native untuk MTP. Untuk menggunakannya, Anda harus menentukan runner pengujian seperti Microsoft.Testing.Platform dalam global.json:

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Penting

Dalam mode ini, ekstra -- tidak lagi digunakan.

Memperbarui dotnet test pemanggilan

Opsi dotnet test baris perintah dibagi menjadi dua kategori: argumen terkait build dan yang terkait pengujian.

Argumen terkait build tidak relevan dengan platform pengujian dan karenanya tidak perlu diperbarui untuk platform baru. Di sini tercantum argumen terkait build.

  • -a|--arch <ARCHITECTURE>
  • --artifacts-path <ARTIFACTS_DIR>
  • -c|--configuration <CONFIGURATION>
  • -f|--framework <FRAMEWORK>
  • -e|--environment <NAME="VALUE">
  • --interactive
  • --no-build
  • --nologo
  • --no-restore
  • -o|--output <OUTPUT_DIRECTORY>
  • --os <OS>
  • -r|--runtime <RUNTIME_IDENTIFIER>
  • -v|--verbosity <LEVEL>

Argumen terkait pengujian khusus VSTest dan perlu diubah agar sesuai dengan platform baru. Tabel berikut ini memperlihatkan pemetaan antara argumen VSTest dan platform baru:

Argumen VSTest Argumen platform baru
--test-adapter-path <ADAPTER_PATH> Tidak relevan untuk MTP
--blame Tidak relevan untuk MTP
--blame-crash --crashdump (memerlukan ekstensi Crash dump)
--blame-crash-dump-type <DUMP_TYPE> --crashdump-type (memerlukan ekstensi Crash dump)
--blame-crash-collect-always Tidak didukung
--blame-hang --hangdump (memerlukan ekstensi Hang dump)
--blame-hang-dump-type <DUMP_TYPE> --hangdump-type (memerlukan ekstensi Hang dump)
--blame-hang-timeout <TIMESPAN> --hangdump-timeout (memerlukan ekstensi Hang dump)
--collect <DATA_COLLECTOR_NAME> Tergantung pada pengumpul data
-d\|--diag <LOG_FILE> --diagnostic
--filter <EXPRESSION> Bergantung pada kerangka kerja pengujian yang dipilih
-l\|--logger <LOGGER> Tergantung pada pencatat
--results-directory <RESULTS_DIR> --results-directory <RESULTS_DIR>
-s\|--settings <SETTINGS_FILE> Bergantung pada kerangka kerja pengujian yang dipilih
-t\|--list-tests --list-tests
-- <RunSettings arguments> --test-parameter (disediakan oleh VSTestBridge)

--collect

--collect adalah titik ekstensibilitas umum di VSTest untuk pengumpul data apa pun. Model ekstensibilitas MTP berbeda dan tidak ada argumen terpusat seperti itu yang akan digunakan oleh semua pengumpul data. Dengan MTP, setiap pengumpul data dapat menambahkan opsi baris perintahnya sendiri. Misalnya, menjalankan Microsoft CodeCoverage melalui VSTest mungkin mirip dengan yang berikut ini:

dotnet test --collect "Code Coverage;Format=cobertura"

Dengan MTP, ini menjadi:

dotnet test --coverage --coverage-output-format cobertura

Penting

Seperti yang dijelaskan sebelumnya, saat menggunakan MTP dengan dotnet test berbasis VSTest, diperlukan -- tambahan sebelum argumen yang dimaksudkan untuk diteruskan ke platform. Jadi, ini menjadi dotnet test -- --coverage --coverage-output-format cobertura.

--filter

--filter adalah filter berbasis VSTest.

MSTest dan NUnit mendukung format filter yang sama bahkan saat berjalan dengan MTP.

xUnit.net, tidak mendukung format filter yang sama saat berjalan dengan MTP. Anda harus bermigrasi dari filter berbasis VSTest ke dukungan filter baru di xunit.v3, yang disediakan menggunakan opsi baris perintah berikut.

xUnit.net pengaturan khusus:

  • --filter-class
  • --filter-not-class
  • --filter-method
  • --filter-not-method
  • --filter-namespace
  • --filter-not-namespace
  • --filter-trait
  • --filter-not-trait
  • --filter-query

Untuk informasi selengkapnya, lihat Dokumentasi Microsoft.Testing.Platform untuk xUnit.net dan Bahasa Filter Kueri untuk xUnit.net.

--logger

Yang biasa disebut "pencatat" dalam VSTest disebut "reporter" dalam MTP. Dalam MTP, logging secara eksplisit hanya untuk tujuan diagnosis.

Mirip dengan --collect, --logger adalah titik ekstensibilitas umum di VSTest untuk logger apa pun (atau, dalam konteks MTP, reporter apa pun). Setiap reporter MTP bebas untuk menambahkan opsi baris perintahnya sendiri, oleh karena itu tidak ada opsi baris perintah terpusat seperti VSTest --logger.

Salah satu pencatat VSTest yang sangat umum digunakan adalah pencatat TRX. Logger ini biasanya digunakan sebagai berikut:

dotnet test --logger trx

Dengan MTP, perintah menjadi:

dotnet test --report-trx

Penting

Untuk menggunakan --report-trx, Anda harus menginstal paket NuGet Microsoft.Testing.Extensions.TrxReport.

Penting

Seperti yang dijelaskan sebelumnya, saat menggunakan MTP dengan VSTest berbasis dotnet test, diperlukan -- tambahan sebelum argumen yang dimaksudkan untuk diteruskan ke platform. Jadi, ini menjadi dotnet test -- --report-trx.

--settings

VSTest --settings digunakan untuk menentukan file RunSettings untuk uji coba. RunSettings tidak didukung oleh MTP inti dan digantikan oleh file konfigurasi yang lebih modern testconfig.json . Namun, MSTest dan NUnit masih mendukung RunSettings lama saat menjalankan MTP dan --settings masih didukung.

vstest.console.exe

Jika Anda menggunakan vstest.console.exe secara langsung, sebaiknya ganti dengan perintah dotnet test.

Eksplorasi Uji

Saat menggunakan Visual Studio atau Visual Studio Code Test Explorer, Anda mungkin perlu mengaktifkan dukungan untuk MTP.

Visual Studio

Visual Studio Test Explorer mendukung MTP yang dimulai dengan versi 17.14. Jika Anda menggunakan versi yang lebih lama, Anda mungkin perlu memperbarui Visual Studio ke versi terbaru.

Visual Studio Code

Visual Studio Code dengan C# DevKit mendukung MTP.

Azure DevOps

Saat menggunakan tugas Azure DevOps, Anda mungkin perlu memperbarui alur untuk menggunakan MTP, tergantung pada tugas mana yang Anda gunakan.

Tugas VSTest

Jika Anda menggunakan tugas VSTest di Azure DevOps, Anda dapat menggantinya dengan tugas .NET Core.

Aktivitas .NET Core CLI

  • Jika Anda telah meneruskan arguments kustom ke tugas, ikuti panduan yang sama untuk migrasi dotnet test.

  • Jika Anda menggunakan tugas DotNetCoreCLI tanpa mendaftar untuk pengalaman MTP asli pada .NET SDK versi 10 dan yang lebih baru melalui berkas global.json, Anda perlu mengatur tugas arguments agar menunjuk ke direktori hasil yang benar dan ke laporan TRX yang diminta. Contohnya:

    - task: DotNetCoreCLI@2
      displayName: Run unit tests
      inputs:
        command: 'test'
        arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
    

Perbedaan perilaku antara VSTest dan MTP

Menjalankan tes nol

Jika rakitan pengujian menjalankan nol pengujian, VSTest mentolerirnya dan keluar dengan sukses. Namun, MTP gagal dengan kode keluar 8. Ada beberapa cara untuk mengatasi hal ini:

  • Lewatkan --ignore-exit-code 8 saat menjalankan tes Anda.

  • Jika Anda ingin mengabaikan kode keluar tersebut untuk proyek pengujian tertentu, tambahkan yang berikut ini dalam file proyek:

    <PropertyGroup>
      <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
    </PropertyGroup>
    
  • TESTINGPLATFORM_EXITCODE_IGNORE Gunakan variabel lingkungan.

Pelestarian InputEncoding pada Console

Jika Anda menjalankan pengujian di konsol tempat halaman kode diubah secara eksplisit (misalnya, di Azure DevOps, halaman kode diatur ke 65001 yang sesuai dengan UTF8), perilakunya dapat berbeda antara VSTest dan MTP.

  • Dengan MTP, pengodean itu selalu dipertahankan.
  • Dengan VSTest tidak berjalan dalam mode isolasi (perilaku default vstest.console), pengodean tersebut dipertahankan, mirip dengan MTP.
  • Dengan VSTest berjalan dalam mode isolasi (perilaku default dari dotnet test), pengodean tersebut tidak dipertahankan dalam testhost, yang merupakan proses untuk menjalankan pengujian.

Petunjuk / Saran

Alasan pengodean tidak dipertahankan dengan mode isolasi VSTest adalah bahwa proses testhost dimulai dengan CreateNoWindow = true. Jadi tidak terhubung dengan konsol asli.

Jika Anda memiliki pengujian yang memulai proses anak lain dan mengalihkan output standarnya, Anda mungkin menghadapi masalah jika semua hal berikut berlaku:

  • Halaman kode konsol diatur ke 65001 (UTF8). Ini bisa terjadi pada CI tetapi umumnya tidak secara lokal. Untuk mendapatkan perilaku lokal yang mirip dengan di CI, jalankan chcp 65001 sebelum menjalankan pengujian.
  • Proses anak dimulai dengan encoding non-UTF8. Ini juga dapat terjadi jika pengujian Anda sendiri juga menetapkan CreateNoWindow = true.

Ini sangat bermasalah ketika proses anak tidak mengharapkan untuk melihat byte UTF8 BOM (Byte-Order-Mark), yang mungkin diperoleh dalam skenario sebelumnya pada .NET Framework.

Karena perbedaan perilaku ini cenderung bermasalah khusus untuk byte BOM, solusinya adalah mengatur InputEncoding selama inisialisasi perakitan ke UTF8 tanpa BOM:

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

Solusi yang berbeda untuk itu adalah tidak menggunakan CreateNoWindow = true untuk proses anak yang mengalihkan input standar.