Tanya jawab umum Pengujian Unit Langsung

Pengujian Unit Langsung berfungsi dengan tiga kerangka kerja pengujian unit populer yang tercantum dalam tabel berikut. Versi minimum adaptor dan kerangka kerja yang didukung juga tercantum dalam tabel. Kerangka kerja pengujian unit semuanya tersedia dari NuGet.org.

Jika Anda memiliki proyek pengujian berbasis MSTest yang lebih lama yang mereferensikan Microsoft.VisualStudio.QualityTools.UnitTestFramework dan Anda tidak ingin pindah ke paket MSTest NuGet yang lebih baru, tingkatkan ke Visual Studio 2019 atau Visual Studio 2017.

Ya. Pengujian Unit Langsung berfungsi dengan .NET Core dan .NET Framework.

Jendela Output (saat drop-down Pengujian Unit Langsung dipilih) harus memberi tahu Anda mengapa Pengujian Unit Langsung tidak berfungsi. Pengujian Unit Langsung mungkin tidak berfungsi karena salah satu alasan berikut:

• Jika paket NuGet yang dirujuk oleh proyek dalam solusi belum dipulihkan, Pengujian Unit Langsung tidak akan berfungsi. Melakukan build eksplisit solusi atau memulihkan paket NuGet dalam solusi sebelum mengaktifkan Pengujian Unit Langsung harus menyelesaikan masalah ini.

• Jika Anda menggunakan pengujian berbasis MSTest dalam proyek Anda, pastikan Anda menghapus referensi ke Microsoft.VisualStudio.QualityTools.UnitTestFramework, dan menambahkan referensi ke paket MSTest NuGet terbaru, MSTest.TestAdapter (diperlukan versi minimum 1.1.11) dan MSTest.TestFramework (diperlukan versi minimum 1.1.11). Untuk informasi selengkapnya, lihat bagian "Kerangka kerja pengujian yang didukung" di artikel Menggunakan Pengujian Unit Langsung di Visual Studio.

• Setidaknya satu proyek dalam solusi Anda harus memiliki referensi NuGet atau referensi langsung ke kerangka kerja pengujian xUnit, NUnit, atau MSTest. Proyek ini juga harus mereferensikan paket NuGet adaptor pengujian Visual Studio yang sesuai.

Kesalahan build dilaporkan ke jendela Output saat drop-down Pengujian Unit Langsung dipilih. Ada beberapa masalah umum yang disebabkan oleh konfigurasi yang salah dalam wizard penyiapan yang dapat menyebabkan masalah build dalam Pengujian Unit Langsung.

• Jika properti Akar Ruang Kerja terlalu panjang, ada kemungkinan build akan gagal karena pengecualian yang menunjukkan bahwa jalur terlalu panjang.

• Jika properti Akar Repositori tidak menunjuk ke akar repositori, ruang kerja akan diisi dengan kumpulan file yang salah.

• Untuk repositori git, properti Kecualikan file biasanya menghindari penyalinan file yang ditentukan dalam file gitignore . Namun, dimungkinkan untuk memeriksa file ke repositori git yang diabaikan, atau dimungkinkan untuk menjalankan alat yang menghasilkan file secara otomatis, tetapi ini tidak dihasilkan selama build. Dalam kasus ini, opsi "<Kustom>" harus dipilih dan sekumpulan aturan kustom yang hanya mencantumkan folder artefak yang harus dicantumkan.

Selain masalah yang dijelaskan sebelumnya, konfigurasi proyek berikut yang mungkin tidak dibuat dengan benar.

• Jika dependensi proyek ditentukan sebagai konfigurasi solusi global dan bukan untuk ProjectReferences setiap proyek, Pengujian Unit Langsung mungkin akhirnya membangun serangkaian proyek yang salah. Untuk memperbaikinya, tambahkan referensi eksplisit antar proyek.

• Hingga daftar putar Pengujian Unit Langsung dipilih, Pengujian Unit Langsung tidak akan membangun proyek apa pun. Untuk memperbaikinya, sertakan beberapa pengujian dalam daftar putar Pengujian Unit Langsung.

• Jika Anda menggunakan pengujian berbasis MSTest dalam proyek Anda, pastikan Anda menghapus referensi ke Microsoft.VisualStudio.QualityTools.UnitTestFramework, dan menambahkan referensi ke paket MSTest NuGet terbaru, MSTest.TestAdapter (versi minimum 1.1.11 diperlukan) dan MSTest.TestFramework (versi minimum 1.1.11 diperlukan). Untuk informasi selengkapnya, lihat Kerangka kerja pengujian yang didukung.

• Setidaknya satu proyek dalam solusi Anda harus memiliki referensi NuGet atau referensi langsung ke kerangka kerja pengujian xUnit, NUnit, atau MSTest. Proyek ini juga harus mereferensikan paket NuGet adaptor pengujian Visual Studio yang sesuai. Adaptor pengujian Visual Studio juga dapat dirujuk melalui file .runsettings. File .runsettings harus memiliki entri seperti contoh berikut:

<RunSettings>
    <RunConfiguration>
          <TestAdaptersPaths>path-to-your-test-adapter</TestAdaptersPaths>
    </RunConfiguration>
</RunSettings>

• Masalah umum adalah bahwa tidak semua file disalin ke folder pengujian. Anda mungkin harus menambahkan beberapa item Dependensi Pengujian Unit Langsung ke file csproj .

• Masalah lain adalah batas waktu. Karena Pengujian Unit Langsung menjalankan pengujian tanpa batas waktu, pengujian tersebut secara otomatis membatalkan eksekusi jika pengujian berjalan terlalu lama. Anda dapat meningkatkan batas waktu dalam Wizard proyek.

• Jika beberapa proyek dalam solusi mereferensikan paket adaptor pengujian NuGet, masing-masing proyek harus ditingkatkan ke versi yang didukung.

• Pastikan file MSBuild .props yang diimpor dari paket adaptor pengujian juga diperbarui dengan benar. Periksa versi/jalur paket NuGet dari impor, yang biasanya dapat ditemukan di dekat bagian atas file proyek, seperti berikut ini:

    <Import Project="..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props" Condition="Exists('..\packages\xunit.runner.visualstudio.2.2.0\build\net20\xunit.runner.visualstudio.props')" />
  

Jika solusi Anda memerlukan langkah-langkah kustom untuk membangun instrumentasi (Pengujian Unit Langsung) yang tidak diperlukan untuk build non-instrumented "reguler", maka Anda dapat menambahkan kode ke file proyek atau .targets yang memeriksa BuildingForLiveUnitTesting properti dan melakukan langkah-langkah build pra/pasca kustom. Anda juga dapat memilih untuk menghapus langkah-langkah build tertentu (seperti menerbitkan atau membuat paket) atau untuk menambahkan langkah build (seperti menyalin prasyarat) ke build Pengujian Unit Langsung berdasarkan properti proyek ini. Menyesuaikan build Anda berdasarkan properti ini tidak mengubah build reguler Anda dengan cara apa pun, dan hanya berdampak pada build Pengujian Unit Langsung.

Misalnya, mungkin ada target yang menghasilkan paket NuGet selama build reguler. Anda mungkin tidak ingin paket NuGet dihasilkan setelah setiap pengeditan yang Anda buat. Jadi Anda dapat menonaktifkan target tersebut di build Pengujian Unit Langsung dengan melakukan sesuatu seperti berikut:

<Target Name="GenerateNuGetPackages" BeforeTargets="AfterBuild" Condition="'$(BuildingForLiveUnitTesting)' != 'true'">
    <Exec Command='"$(MSBuildThisFileDirectory)..\tools\GenPac" '/>
</Target>

Ada beberapa perbedaan:

• Menjalankan atau men-debug pengujian dari jendela Test Explorer menjalankan biner reguler, sedangkan Pengujian Unit Langsung menjalankan biner berinstrumen. Jika Anda ingin men-debug biner berinstrumen, menambahkan panggilan metode Debugger.Launch dalam metode pengujian Anda menyebabkan debugger diluncurkan setiap kali metode tersebut dijalankan (termasuk ketika dijalankan oleh Pengujian Unit Langsung), dan Anda kemudian dapat melampirkan dan men-debug biner berinstrumen. Namun, kami berharap instrumentasi ini transparan bagi Anda untuk sebagian besar skenario pengguna, dan Anda tidak perlu men-debug biner berinstrumen.

• Pengujian Unit Langsung tidak membuat domain aplikasi baru untuk menjalankan pengujian, tetapi pengujian yang dijalankan dari jendela Test Explorer membuat domain aplikasi baru.

• Pengujian Unit Langsung menjalankan pengujian di setiap rakitan pengujian secara berurutan. Di Test Explorer, Anda dapat memilih untuk menjalankan beberapa pengujian secara paralel.

• Test Explorer menjalankan pengujian di apartemen berulir tunggal (STA) secara default, sedangkan Pengujian Unit Langsung menjalankan pengujian di apartemen multi-utas (MTA). Untuk menjalankan pengujian MSTest di STA dalam Pengujian Unit Langsung, hiasi metode pengujian atau kelas yang berisi dengan atribut <STATestMethod> atau <STATestClass> yang dapat ditemukan dalam paket NuGet MSTest.STAExtensions 1.0.3-beta. Untuk NUnit, hiasi metode pengujian dengan atribut <RequiresThread(ApartmentState.STA)>, dan untuk xUnit, dengan atribut <STAFact>.

Lihat bagian "Sertakan dan kecualikan proyek pengujian dan metode pengujian" dari artikel Menggunakan Pengujian Unit Langsung di Visual Studio untuk pengaturan khusus pengguna. Menyertakan atau mengecualikan pengujian berguna ketika Anda ingin menjalankan serangkaian pengujian tertentu untuk sesi edit tertentu atau untuk mempertahankan preferensi pribadi Anda sendiri.

Untuk pengaturan khusus solusi, Anda dapat menerapkan atribut System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute secara terprogram untuk mengecualikan metode, properti, kelas, atau struktur agar tidak diinstrumentasikan oleh Pengujian Unit Langsung. Selain itu, Anda juga dapat mengatur properti <ExcludeFromCodeCoverage> ke true dalam file proyek Anda untuk mengecualikan seluruh proyek agar tidak diinstrumentasikan. Pengujian Unit Langsung masih akan menjalankan pengujian yang belum diinstrumentasikan, tetapi cakupannya tidak akan divisualisasikan.

Anda juga dapat memeriksa apakah Microsoft.CodeAnalysis.LiveUnitTesting.Runtime dimuat di domain aplikasi saat ini dan menonaktifkan pengujian berdasarkan alasannya. Misalnya, Anda dapat melakukan sesuatu seperti berikut ini dengan xUnit:

[ExcludeFromCodeCoverage]
public class SkipLiveFactAttribute : FactAttribute
{
   private static bool s_lutRuntimeLoaded = AppDomain.CurrentDomain.GetAssemblies().Any(a => a.GetName().Name ==
                                            "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
   public override string Skip => s_lutRuntimeLoaded ? "Test excluded from Live Unit Testing" : "";
}

public class Class1
{
   [SkipLiveFact]
   public void F()
   {
      Assert.True(true);
   }
}

Solusi Anda dapat membangun meskipun Anda tidak melakukan pengeditan jika proses build menghasilkan kode sumber yang merupakan bagian dari solusi itu sendiri, dan file target build Anda tidak memiliki input dan output yang sesuai yang ditentukan. Target harus diberi daftar input dan output sehingga MSBuild dapat melakukan pemeriksaan terbaru yang sesuai dan menentukan apakah build baru diperlukan.

Pengujian Unit Langsung memulai build setiap kali mendeteksi bahwa file sumber telah berubah. Karena build solusi Anda menghasilkan file sumber, Pengujian Unit Langsung masuk ke perulangan build tak terbatas. Namun, jika input dan output target diperiksa ketika Pengujian Unit Langsung memulai build kedua (setelah mendeteksi file sumber yang baru dihasilkan dari build sebelumnya), itu rusak dari perulangan build karena pemeriksaan input dan output menunjukkan bahwa semuanya sudah diperbarui.

Anda mungkin tidak melihat ikon di editor jika rakitan tempat Pengujian Unit Langsung beroperasi tidak diinstrumentasikan karena alasan apa pun. Misalnya, Pengujian Unit Langsung tidak kompatibel dengan proyek yang mengatur <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>. Dalam hal ini, proses build Anda perlu diperbarui untuk menghapus pengaturan ini atau mengubahnya ke true agar Pengujian Unit Langsung berfungsi. 

Anda dapat melakukan beberapa hal untuk mengumpulkan log yang lebih rinci:

• BukaOpsi>Alat>Pengujian Unit Langsung dan ubah opsi pengelogan ke Verbose. Pengelogan verbose menyebabkan log yang lebih rinci ditampilkan di jendela Output.

• Atur variabel lingkungan pengguna LiveUnitTesting_BuildLog ke nama file yang ingin Anda gunakan untuk mengambil log MSBuild. Pesan log MSBuild terperinci dari build Pengujian Unit Langsung kemudian dapat diambil dari file tersebut.

• Atur variabel lingkungan pengguna LiveUnitTesting_TestPlatformLog ke 1 untuk mengambil log Platform Pengujian. Pesan log Platform Pengujian terperinci dari eksekusi Pengujian Unit Langsung kemudian dapat diambil dari [Solution Root]\.vs\[Solution Name]\log\[VisualStudio Process ID].

• Buat variabel lingkungan tingkat pengguna bernama VS_UTE_DIAGNOSTICS dan atur ke 1 (atau nilai apa pun) dan mulai ulang Visual Studio. Sekarang Anda akan melihat banyak pengelogan di tab Output - Pengujian di Visual Studio.

Tidak, Anda tidak boleh membuka atau mengedit file di bawah direktori build dan pengujian folder ruang kerja. Pengujian Unit Langsung harus mengelola semua file di folder src , agar tetap sinkron antara Akar Repositori dan Akar Ruang Kerja.

Ya, tetapi Anda perlu memastikannya diaktifkan. Jika Anda menggunakan Dev Drive, pastikan filter sistem file yang diproyeksikan (ProjFS) diaktifkan. Misalnya, perintah berikut mengaktifkan ProjFS dan Windows Defender:

fsutil devdrv setfiltersallowed PrjFlt, WdFilter

Lihat juga

• Pengujian Unit Langsung