Mengisolasi kode yang sedang diuji dengan Microsoft Fakes
Isolasi kode adalah strategi pengujian yang sering diterapkan dengan alat seperti Microsoft Fakes, di mana kode yang Anda uji dipisahkan dari aplikasi lainnya. Pemisahan ini dicapai dengan mengganti bagian aplikasi yang berinteraksi dengan kode di bawah pengujian dengan stub atau shim. Ini adalah potongan-potongan kecil kode yang dikendalikan oleh pengujian Anda, yang mensimulasikan perilaku bagian aktual yang digantikan.
Manfaat dari pendekatan ini adalah memungkinkan Anda untuk fokus pada pengujian fungsionalitas spesifik kode dalam isolasi. Jika pengujian gagal, Anda tahu penyebabnya adalah dalam kode terisolasi dan bukan di tempat lain. Selain itu, penggunaan stub dan shim, yang disediakan oleh Microsoft Fakes, memungkinkan Anda untuk menguji kode Anda meskipun bagian lain dari aplikasi Anda belum berfungsi.
Persyaratan
- Visual Studio Enterprise
- Proyek .NET Framework
- .NET Core, .NET 5.0 atau yang lebih baru, dan proyek bergaya SDK mendukung pratinjau di Visual Studio 2019 Update 6, dan diaktifkan secara default di Update 8. Untuk informasi selengkapnya, lihat Microsoft Fakes untuk proyek bergaya SDK dan .NET Core.
Catatan
Pembuatan profil dengan Visual Studio tidak tersedia untuk pengujian yang menggunakan Microsoft Fakes.
Peran Microsoft Fakes dalam Isolasi Kode
Microsoft Fakes memainkan peran kunci dalam isolasi kode dengan menyediakan dua mekanisme - stub dan shim.
Stub: Ini digunakan untuk mengganti kelas dengan pengganti kecil yang mengimplementasikan antarmuka yang sama. Ini mengharuskan aplikasi Anda dirancang singgah sehingga setiap komponen hanya bergantung pada antarmuka, bukan pada komponen lain.
Shim: Ini digunakan untuk memodifikasi kode aplikasi Anda yang dikompilasi saat runtime. Alih-alih melakukan panggilan metode tertentu, aplikasi menjalankan kode shim yang disediakan pengujian Anda. Shim dapat mengganti panggilan ke rakitan yang tidak dapat Anda ubah, seperti rakitan .NET.
Biasanya, stub digunakan untuk panggilan dalam solusi Visual Studio Anda, dan shim untuk panggilan ke rakitan lain yang dirujuk. Ini karena dalam solusi Anda, ada baiknya untuk memisahkan komponen dengan mendefinisikan antarmuka dengan cara yang diperlukan stubbing. Namun, rakitan eksternal sering kali tidak dilengkapi dengan definisi antarmuka terpisah, sehingga shim digunakan sebagai gantinya.
Rekomendasi Kapan Menggunakan Stub
Stub biasanya digunakan untuk panggilan dalam solusi Visual Studio Anda karena ini adalah praktik yang baik untuk memisahkan komponen dengan menentukan antarmuka dengan cara yang diperlukan stubbing. Namun, rakitan eksternal, seperti System.dll, biasanya tidak disediakan dengan definisi antarmuka terpisah, sehingga shim akan digunakan dalam kasus ini sebagai gantinya.
Menggunakan stub melibatkan desain aplikasi Anda sehingga komponen yang berbeda tidak bergantung satu sama lain, tetapi hanya pada definisi antarmuka. Pemisahan ini membuat aplikasi lebih kuat dan fleksibel, dan memungkinkan Anda untuk menghubungkan komponen di bawah pengujian untuk stub implementasi antarmuka untuk tujuan pengujian.
Dalam praktiknya, Anda dapat menghasilkan jenis stub dari definisi antarmuka di Visual Studio, lalu mengganti komponen nyata dengan stub dalam pengujian Anda.
Rekomendasi Kapan Menggunakan Shim
Meskipun stub digunakan untuk panggilan dalam solusi Visual Studio Anda, shim biasanya digunakan untuk panggilan ke rakitan lain yang dirujuk. Ini karena rakitan eksternal seperti System.dll biasanya tidak disediakan dengan definisi antarmuka terpisah, sehingga shim harus digunakan sebagai gantinya.
Namun, ada beberapa faktor yang perlu dipertimbangkan saat menggunakan shim:
Performa: Shim berjalan lebih lambat karena mereka menulis ulang kode Anda saat runtime. Stub tidak memiliki overhead performa ini dan secepat metode virtual dapat berjalan.
Metode statis, jenis tertutup: Anda hanya dapat menggunakan stub untuk mengimplementasikan antarmuka. Oleh karena itu, jenis stub tidak dapat digunakan untuk metode statis, metode non-virtual, metode virtual yang disegel, metode dalam jenis tertutup, dan sebagainya.
Jenis internal: Stub dan shim dapat digunakan dengan jenis internal yang dapat diakses dengan menggunakan atribut InternalsVisibleToAttributeassembly .
Metode privat: Shim dapat mengganti panggilan ke metode privat jika semua jenis pada tanda tangan metode terlihat. Stub hanya dapat menggantikan metode yang terlihat.
Antarmuka dan metode abstrak: Stub menyediakan implementasi antarmuka dan metode abstrak yang dapat digunakan dalam pengujian. Shim tidak dapat melengkapi antarmuka instrumen dan metode abstrak, karena tidak memiliki isi metode.
Transisi Microsoft Fakes di .NET Framework ke Proyek Gaya SDK
Transisi proyek pengujian .NET Framework Anda yang menggunakan microsoft Fakes ke proyek .NET Framework, .NET Core, atau .NET 5+ bergaya SDK.
Anda akan memerlukan perubahan minimal dalam .NET Framework yang disiapkan untuk Microsoft Fakes untuk transisi ke .NET Core atau .NET 5.0. Kasus yang harus Anda pertimbangkan adalah:
Jika Anda menggunakan templat proyek kustom, Anda perlu memastikan bahwa templat tersebut bergaya SDK dan build untuk kerangka kerja target yang kompatibel.
Jenis tertentu ada di rakitan yang berbeda di .NET Framework dan .NET Core/.NET 5.0 (misalnya,
System.DateTimeada diSystem/mscorlib.NET Framework, dan diSystem.Runtime.NET Core dan .NET 5.0), dan dalam skenario ini Anda perlu mengubah rakitan yang dipalsukan.Jika Anda memiliki referensi perakitan ke rakitan palsu dan proyek pengujian, Anda mungkin melihat peringatan build tentang referensi yang hilang yang mirip dengan:
(ResolveAssemblyReferences target) -> warning MSB3245: Could not resolve this reference. Could not locate the assembly "AssemblyName.Fakes". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.Peringatan ini dikarenakan adanya perubahan yang diperlukan yang dilakukan pada pembuatan Fakes dan dapat diabaikan. Ini dapat dihindari dengan menghapus referensi perakitan dari file proyek, karena kita sekarang secara implisit menambahkannya selama build.
Menjalankan pengujian Microsoft Fakes
Selama rakitan Microsoft Fakes ada di direktori yang dikonfigurasi FakesAssemblies (Defaultnya adalah $(ProjectDir)FakesAssemblies), Anda dapat menjalankan pengujian menggunakan tugas vstest.
Pengujian terdistribusi dengan tugas vstest proyek .NET Core dan .NET 5+ menggunakan Microsoft Fakes memerlukan Pratinjau 20201020-06 Pembaruan 9 Visual Studio 2019 dan yang lebih tinggi.
Kompatibilitas dan Dukungan untuk Microsoft Fakes di Versi .NET dan Visual Studio yang Berbeda
Microsoft Fakes dalam proyek lama yang menargetkan .NET Framework (gaya non-SDK).
- Pembuatan rakitan Microsoft Fakes didukung di Visual Studio Enterprise 2015 dan yang lebih tinggi.
- Pengujian Microsoft Fakes dapat berjalan dengan semua paket Microsoft.TestPlatform NuGet yang tersedia.
- Cakupan kode didukung untuk proyek pengujian menggunakan Microsoft Fakes di Visual Studio Enterprise 2015 dan yang lebih tinggi.
Microsoft Fakes dalam proyek .NET Framework gaya SDK, .NET Core, dan .NET 5.0 atau yang lebih baru
- Pembuatan rakitan Microsoft Fakes dipratinjau di Visual Studio Enterprise 2019 Update 6 dan diaktifkan secara default di Pembaruan 8.
- Pengujian Microsoft Fakes untuk proyek yang menargetkan .NET Framework dapat berjalan dengan semua paket Microsoft.TestPlatform NuGet yang tersedia.
- Pengujian Microsoft Fakes untuk proyek yang menargetkan .NET Core dan .NET 5.0 atau yang lebih baru dapat berjalan dengan paket NuGet Microsoft.TestPlatform dengan versi 16.9.0-preview-20210106-01 dan yang lebih tinggi.
- Cakupan kode didukung untuk proyek pengujian yang menargetkan .NET Framework menggunakan Microsoft Fakes di Visual Studio Enterprise versi 2015 dan yang lebih tinggi.
- Dukungan cakupan kode untuk proyek pengujian yang menargetkan .NET Core dan .NET 5.0 atau yang lebih baru menggunakan Microsoft Fakes tersedia di Visual Studio 2019 pembaruan 9 dan yang lebih tinggi.