Saya bertanya-tanya bagaimana cara menggunakan NUnit dengan benar. Pertama, saya membuat proyek uji terpisah yang menggunakan proyek utama saya sebagai referensi. Tetapi dalam kasus itu, saya tidak dapat menguji metode privat. Dugaan saya adalah bahwa saya perlu memasukkan kode tes saya ke dalam kode utama saya ?! - Sepertinya itu bukan cara yang benar untuk melakukannya. (Saya tidak menyukai gagasan kode pengiriman dengan tes di dalamnya.)
Bagaimana Anda menguji metode privat dengan NUnit?
Jawaban:
Umumnya, pengujian unit membahas antarmuka publik kelas, dengan teori bahwa penerapannya tidak material, selama hasilnya benar dari sudut pandang klien.
Jadi, NUnit tidak menyediakan mekanisme apa pun untuk menguji anggota non-publik.
System.Reflectionmemungkinkan Anda untuk mengakses dan memanggil metode non-publik menggunakan bendera yang mengikat, sehingga Anda dapat meretas NUnit atau menyiapkan kerangka kerja Anda sendiri. Atau (lebih mudah, menurut saya), Anda dapat menyiapkan tanda waktu kompilasi (#Jika PENGUJIAN) untuk mengubah pengubah akses, memungkinkan Anda menggunakan kerangka kerja yang ada.
Meskipun saya setuju bahwa fokus pengujian unit haruslah antarmuka publik, Anda mendapatkan kesan kode yang jauh lebih terperinci jika Anda juga menguji metode pribadi. Kerangka pengujian MS memungkinkan hal ini melalui penggunaan PrivateObject dan PrivateType, NUnit tidak. Yang saya lakukan adalah:
private MethodInfo GetMethod(string methodName)
{
if (string.IsNullOrWhiteSpace(methodName))
Assert.Fail("methodName cannot be null or whitespace");
var method = this.objectUnderTest.GetType()
.GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance);
if (method == null)
Assert.Fail(string.Format("{0} method not found", methodName));
return method;
}Dengan cara ini berarti Anda tidak perlu berkompromi dengan enkapsulasi demi kemudahan pengujian. Ingatlah bahwa Anda harus memodifikasi BindingFlags jika Anda ingin menguji metode statis privat. Contoh di atas hanyalah untuk metode contoh.
Pola umum untuk menulis tes unit adalah dengan hanya menguji metode publik.
Jika Anda menemukan bahwa Anda memiliki banyak metode privat yang ingin Anda uji, biasanya ini adalah tanda bahwa Anda harus mengubah kode Anda.
Salah jika membuat metode ini menjadi publik di kelas tempat mereka tinggal saat ini. Itu akan memutuskan kontrak yang Anda ingin kelas itu miliki.
Mungkin benar untuk memindahkan mereka ke kelas helper dan menjadikannya publik di sana. Kelas ini mungkin tidak diekspos oleh API Anda.
Dengan cara ini kode pengujian tidak pernah dicampur dengan kode publik Anda.
Masalah serupa sedang menguji kelas privat yaitu. kelas yang tidak Anda ekspor dari perakitan Anda. Dalam hal ini Anda dapat secara eksplisit menjadikan perakitan kode pengujian Anda sebagai teman dari perakitan kode produksi menggunakan atribut InternalsVisibleTo.
Dimungkinkan untuk menguji metode privat dengan mendeklarasikan rakitan uji Anda sebagai rakitan teman dari rakitan target yang Anda uji. Lihat tautan di bawah untuk detailnya:
http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx
Ini dapat berguna karena sebagian besar memisahkan kode pengujian dari kode produksi Anda. Saya sendiri tidak pernah menggunakan metode ini karena saya tidak pernah merasa membutuhkannya. Saya kira Anda dapat menggunakannya untuk mencoba dan menguji kasus uji ekstrim yang tidak dapat Anda tiru di lingkungan pengujian untuk melihat bagaimana kode Anda menanganinya.
Seperti yang telah dikatakan, Anda tidak perlu menguji metode privat. Anda lebih dari likley ingin mengubah kode Anda menjadi blok bangunan yang lebih kecil. Salah satu tip yang mungkin membantu Anda ketika Anda datang ke refactor adalah mencoba dan memikirkan tentang domain yang berhubungan dengan sistem Anda dan memikirkan tentang objek 'nyata' yang menghuni domain ini. Objek / kelas Anda di sistem Anda harus berhubungan langsung dengan objek nyata yang akan memungkinkan Anda untuk mengisolasi perilaku yang tepat yang harus dimiliki objek dan juga membatasi tanggung jawab objek. Ini berarti bahwa Anda melakukan refactoring secara logis daripada hanya untuk memungkinkan pengujian metode tertentu; Anda akan dapat menguji perilaku objek.
Jika Anda masih merasa perlu untuk menguji internal maka Anda mungkin juga ingin mempertimbangkan untuk mengejek dalam pengujian Anda karena Anda ingin fokus pada satu bagian kode. Mocking adalah tempat Anda memasukkan dependensi objek ke dalamnya tetapi objek yang dimasukkan bukanlah objek 'nyata' atau produksi. Mereka adalah objek dummy dengan perilaku hardcode untuk memudahkan mengisolasi kesalahan perilaku. Rhino.Mocks adalah kerangka kerja mengejek gratis populer yang pada dasarnya akan menulis objek untuk Anda. TypeMock.NET (produk komersial dengan edisi komunitas tersedia) adalah kerangka kerja yang lebih kuat yang dapat meniru objek CLR. Sangat berguna untuk mengejek kelas SqlConnection / SqlCommand dan Datatable misalnya saat menguji aplikasi database.
Semoga jawaban ini memberi Anda sedikit lebih banyak informasi untuk memberi tahu Anda tentang Pengujian Unit secara umum dan membantu Anda mendapatkan hasil yang lebih baik dari Pengujian Unit.
Saya lebih suka memiliki kemampuan untuk menguji metode privat. Ketika xUnit dimulai, itu dimaksudkan untuk menguji fungsionalitas setelah kode ditulis. Menguji antarmuka sudah cukup untuk tujuan ini.
Pengujian unit telah berkembang menjadi pengembangan yang digerakkan oleh pengujian. Memiliki kemampuan untuk menguji semua metode berguna untuk aplikasi itu.
Pertanyaan ini ada di tahun-tahun yang sudah lanjut, tetapi saya pikir saya akan membagikan cara saya melakukan ini.
Pada dasarnya, saya memiliki semua kelas pengujian unit saya dalam rakitan yang mereka uji dalam ruang nama 'UnitTest' di bawah 'default' untuk rakitan itu - setiap file uji dibungkus dalam:
#if DEBUG
...test code...
#endifmemblokir, dan semua itu berarti bahwa a) itu tidak didistribusikan dalam rilis dan b) saya dapat menggunakan internal/ Friendlevel deklarasi tanpa lompatan lingkaran.
Hal lain yang ditawarkan ini, yang lebih berkaitan dengan pertanyaan ini, adalah penggunaan partialkelas, yang dapat digunakan untuk membuat proxy untuk menguji metode privat, jadi misalnya untuk menguji sesuatu seperti metode privat yang mengembalikan nilai integer:
public partial class TheClassBeingTested
{
private int TheMethodToBeTested() { return -1; }
}di kelas utama assembly, dan kelas pengujian:
#if DEBUG
using NUnit.Framework;
public partial class TheClassBeingTested
{
internal int NUnit_TheMethodToBeTested()
{
return TheMethodToBeTested();
}
}
[TestFixture]
public class ClassTests
{
[Test]
public void TestMethod()
{
var tc = new TheClassBeingTested();
Assert.That(tc.NUnit_TheMethodToBeTested(), Is.EqualTo(-1));
}
}
#endifJelas, Anda perlu memastikan bahwa Anda tidak menggunakan metode ini saat mengembangkan, meskipun rilis build akan segera menunjukkan panggilan yang tidak disengaja jika Anda melakukannya.
Tujuan utama pengujian unit adalah untuk menguji metode publik suatu kelas. Metode publik tersebut akan menggunakan metode privat tersebut. Pengujian unit akan menguji perilaku dari apa yang tersedia untuk umum.
Mohon maaf jika ini tidak menjawab pertanyaan tetapi solusi seperti menggunakan refleksi, pernyataan #if #endif atau membuat metode privat terlihat tidak menyelesaikan masalah. Ada beberapa alasan mengapa metode privat tidak terlihat ... bagaimana jika itu kode produksi dan tim secara retrospektif menulis pengujian unit misalnya.
Untuk proyek yang saya kerjakan hanya MSTest (sayangnya) tampaknya memiliki cara, menggunakan pengakses, untuk menguji unit metode pribadi.
Anda tidak menguji fungsi pribadi. Ada cara untuk menggunakan refleksi untuk masuk ke metode dan properti pribadi. Tetapi itu tidak terlalu mudah dan saya sangat melarang praktik ini.
Anda seharusnya tidak menguji apa pun yang tidak bersifat publik.
Jika Anda memiliki beberapa metode dan properti internal, Anda harus mempertimbangkan untuk mengubahnya menjadi publik, atau mengirimkan pengujian Anda dengan aplikasi (sesuatu yang saya tidak benar-benar melihat sebagai masalah).
Jika pelanggan Anda dapat menjalankan Test-Suite dan melihat bahwa kode yang Anda kirimkan benar-benar "berfungsi", saya tidak melihat ini sebagai masalah (selama Anda tidak memberikan IP Anda melalui ini). Hal-hal yang saya sertakan dalam setiap rilis adalah laporan pengujian dan laporan cakupan kode.
Dalam teori Unit Testing, hanya kontrak yang harus diuji. yaitu hanya anggota umum kelas. Namun dalam praktiknya developer biasanya ingin menguji anggota internal untuk. - dan itu tidak buruk. Ya, ini bertentangan dengan teori, tetapi dalam praktiknya kadang-kadang bisa berguna.
Jadi, jika Anda benar-benar ingin menguji anggota internal, Anda dapat menggunakan salah satu pendekatan ini:
Contoh kode (pseudo code):
public class SomeClass
{
protected int SomeMethod() {}
}
[TestFixture]
public class TestClass : SomeClass{
protected void SomeMethod2() {}
[Test]
public void SomeMethodTest() { SomeMethod2(); }
}Message: Method is not public.
Anda dapat membuat metode Anda dilindungi secara internal, kemudian menggunakan
assembly: InternalsVisibleTo("NAMESPACE")
namespace pengujian Anda.
Karenanya, TIDAK! Anda tidak dapat mengakses metode privat, tetapi ini adalah solusi.
Saya akan membuat paket metode privat terlihat. Dengan cara itu Anda membuatnya cukup pribadi sambil tetap dapat menguji metode tersebut. Saya tidak setuju dengan orang-orang yang mengatakan bahwa antarmuka publik adalah satu-satunya yang harus diuji. Seringkali ada kode yang sangat penting dalam metode privat yang tidak dapat diuji dengan benar hanya melalui antarmuka eksternal.
Jadi intinya adalah jika Anda lebih peduli tentang kode yang benar atau menyembunyikan informasi. Saya akan mengatakan visibilitas paket adalah kompromi yang baik karena untuk mengakses metode tersebut seseorang harus menempatkan kelas mereka di paket Anda. Itu seharusnya membuat mereka berpikir dua kali tentang apakah itu hal yang benar-benar cerdas untuk dilakukan.
Saya seorang pria Java btw, jadi visiblilty paket mungkin disebut sesuatu yang sama sekali berbeda di C #. Cukuplah untuk mengatakan bahwa itu adalah saat dua kelas harus berada di namespace yang sama untuk mengakses metode tersebut.