Kemampuan untuk menulis unit test yang baik adalah fitur penting dari pengembang mana pun. Tetapi bagaimana memahami bahwa tes unit Anda sudah benar? Tes unit yang baik seperti permainan catur yang bagus. Dalam kasus kami, catur adalah pendekatan yang akan kami diskusikan di pos ini. Tidak ada catur terbaik dalam permainan catur karena semuanya tergantung pada posisi (dan pemain) . Demikian juga, dalam pengujian unit Anda tidak harus membedakan hanya satu pendekatan. Dengan kata lain, Anda harus menggunakan semua pendekatan bersama untuk mendapatkan hasil terbaik. Jadi, jika Anda ingin memenangkan permainan ini, selamat datang di bawah potongan.
Debut
Mengapa saya harus menulis unit test?
Anda tidak harus menulis unit test kecuali Anda adalah orang dengan persepsi ekstra-sensor yang dapat menulis kode tanpa bug, Anda memiliki memori super, dapat mengkompilasi kode Anda di kepala Anda atau Anda hanya suka rasa sakit. Kalau tidak, Anda pasti harus menulis unit test, karena mereka mengurangi jumlah bug di fitur baru dan yang ada, mengurangi biaya dan takut untuk mengubah fitur Anda dan memungkinkan refactoring kode Anda. Selain itu, Anda harus selalu menjalankan tes yang ada dan saya sarankan Anda untuk memperhatikan alat pengujian berkelanjutan.
Apa yang harus diuji?
Jelas, dalam pengujian unit Anda menguji perilaku beberapa unit yang terpisah (bukan doa, karena mereka dapat diubah kemudian) . Juga, buatlah aturan untuk menutup dengan unit test semua bug yang Anda temukan untuk membuktikannya telah diperbaiki. Bagaimana dengan cakupan kode? Cakupan kode bukan tujuan, itu hanya ukuran yang membantu Anda memahami bagian mana dari logika yang Anda lupa untuk tutupi dengan unit test. Ini akan menjadi kesalahan besar ketika Anda memutuskan untuk menutupi setiap baris kode dengan tes unit.
Mittelspiel
Uji hanya satu hal
Jangan bingung pengujian unit dengan pengujian integrasi di mana pengujian lebih dari satu hal adalah normal. Gagasan pengujian unit adalah untuk membuktikan bahwa modul aplikasi terpisah berfungsi atau tidak. Anda harus memahami dengan mudah dan pasti perilaku mana dalam kode Anda yang gagal dan bagaimana cara memperbaikinya. Berapa banyak pernyataan yang harus Anda gunakan? Satu! Menggunakan banyak pernyataan mungkin merupakan bau kode yang Anda uji lebih dari satu hal. Selain itu, ada kemungkinan seseorang dapat menambahkan pernyataan baru ke dalam tes Anda alih-alih menulis yang lain. Dan bagaimana Anda bisa memahami bagaimana pernyataan Anda yang lain diselesaikan ketika yang pertama gagal?
Hindari logika
Bug dalam pengujian adalah hal yang paling sulit ditemukan bagi pengembang. Peluang untuk mendapatkan bug dalam kode pengujian Anda meningkat saat Anda memutuskan untuk menambahkan logika ke dalam pengujian Anda. Menjadi lebih sulit untuk membaca, memahami, dan memelihara. Menggunakan for , foreach , if , switch , dan operator lain dalam pengujian mungkin juga merupakan bau kode yang Anda uji lebih dari satu hal.
AAA
Arrange, Act, Assert adalah pola yang umum digunakan yang membantu mengatur kode pengujian Anda menjadi tiga fase yang sesuai. Ini dengan jelas memisahkan apa yang sedang diuji dari langkah pengaturan dan verifikasi. Ini adalah salah satu praktik terbaik dan itu membuat kode pengujian Anda lebih mudah dibaca dan dipelihara. Karena itu, jangan gunakan komentar AAA dalam pengujian Anda jika Anda ingin menjaga kode Anda bersih dan mudah dibaca. Tes yang dibuat secara kompeten mengekspresikan ide AAA bahkan tanpa komentar.
Tetap pada konvensi penamaan
Nama uji harus deskriptif dan dapat dimengerti tidak hanya untuk penulisnya. Ada banyak strategi penamaan tes, tapi saya suka yang Roy Osherove : [MethodName_StateUnderTest_ExpectedBehavior] . Ini memiliki semua informasi yang diperlukan tentang tes dengan cara diformat. Sangat mudah untuk mengikuti strategi ini untuk pengembang mana pun.
Contoh:
public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () public void Sum_simpleValues_Calculated () public void Parse_OnEmptyString_ExceptionThrown() public void Parse_SingleToken_ReturnsEqualTokenValue ()
Tetapi perhatikan bahwa Anda mungkin memiliki konvensi penamaan yang harus Anda ikuti pada proyek Anda saat ini. Jangan mencampurnya.
Tes persiapan data
Membangun data uji dapat membawa kekacauan dan penderitaan ke dalam kode tes Anda. Anda dapat menghadapi situasi ini saat:
- Anda harus mengubah konstruktor model Anda di setiap bagian kode tempat model ini dibuat (ini biasanya terjadi ketika model Anda tidak dapat diubah) ;
- Anda memiliki banyak duplikat kode saat membangun data pengujian Anda;
- Anda harus memasukkan banyak "data ajaib" ke dalam konstruktor model Anda (mis.
new Device("Stub", 10, true, "http"); ) ; - Anda merasa perlu membuat semacam generator data acak;
- sulit bagi Anda untuk membangun koleksi data tes.
Dengan pemikiran ini, Anda harus mempertimbangkan beberapa alternatif umum: Ibu objek dan [Pola pembangun fasih]. Pendekatan ini juga merupakan pemain tim yang baik, sehingga Anda dapat menggunakannya bersama.
Jangan gunakan data acak, karena tes Anda mungkin peka terhadap beberapa jenis nilai. Akibatnya, Anda bisa mendapatkan Heisenbug jahat dalam ujian yang sulit ditemukan dan diperbanyak.
Pelajari kerangka kerja pengujian Anda
Pelajari semua atribut, pernyataan, dan fitur lain dari kerangka pengujian Anda. Ini membantu Anda untuk membuat tes Anda lebih mudah dibaca dan elegan. Misalnya dalam kerangka NUnit Anda dapat menggunakan dua model pernyataan dan Anda dapat memilih satu yang paling Anda sukai:
Assert.AreEqual(StatusCode.OK, response.StatusCode);
atau
Assert.That(StatusCode.OK, Is.EqualTo(response.StatusCode));
Jangan lupa tentang metode pengaturan dan teardown, atribut TestCase dan Kategori, pernyataan pengumpulan. Jangan bingung parameter hasil yang diharapkan dan aktual dalam asersi.
Endspiel
Kode pengujian Anda memiliki hak istimewa yang sama dengan kode produksi Anda yang harus Anda tulis dan pertahankan, jangan lupa tentang prinsip SOLID. Selain itu, tes unit Anda harus dapat dibaca dan ada beberapa alasan mengapa. Pertama, niat tes Anda harus dapat dimengerti dan jelas. Ini berarti Anda tidak perlu membuang waktu saat membaca tes. Kedua, seharusnya mudah untuk mempertahankan pengujian Anda, mendeteksi dan menghilangkan masalah tanpa debugging.
Unit testing adalah filosofi besar yang tidak dapat didiskusikan hanya dalam satu posting. Di sini saya menjelaskan pendekatan umum dan pertanyaan yang sering terkait dengan pengujian unit. Jika Anda ingin menyelam lebih dalam, Anda mungkin menemukan tautan ini menarik:
Blog Roy Osherove
Buku Roy Osherove, "Seni Pengujian Unit"
Tetap tenang dan uji unit