JUnit 4 vs TestNG - Pembaruan 2013 - 2014 [ditutup]

JUnit 4 dan TestNG dulunya sebanding. Apa pro dan kontra dari dua framework pengujian?

Saya membandingkan TestNG dan JUnit4 hari ini, dan keuntungan utama yang dapat saya tunjukkan dengan pengalaman saya yang terbatas dalam kerangka pengujian adalah bahwa TestNG memiliki cara yang lebih elegan dalam menangani pengujian parametri dengan konsep penyedia data.

Sejauh yang saya tahu dengan JUnit4 Anda harus membuat kelas pengujian terpisah untuk setiap set parameter yang ingin Anda uji (dijalankan dengan @RunWith(Parameterized.class)). Dengan TestNG, Anda dapat memiliki beberapa penyedia data dalam satu kelas pengujian, sehingga Anda dapat menyimpan semua pengujian untuk satu kelas dalam satu kelas pengujian juga.

Sejauh ini, itulah satu-satunya hal yang dapat saya tunjukkan sebagai manfaat TestNG dibandingkan JUnit4.

Intellij IDEA menyertakan dukungan untuk TestNG dan JUnit di luar kotak. Namun, Eclipse hanya mendukung JUnit di luar kotak dan membutuhkan plugin TestNG terpasang untuk membuatnya berfungsi.

Namun, masalah yang lebih menjengkelkan yang saya hadapi dengan TestNG adalah bahwa kelas pengujian Anda perlu diperpanjang PowerMockTestCasejika Anda menggunakan PowerMock untuk meniru dependensi dalam pengujian Anda. Rupanya ada cara untuk mengonfigurasi pabrik objek yang perlu diketahui oleh framework pengujian Anda saat menggunakan PowerMock melalui metode khusus, atau melalui testng.xmldefinisi suite, tetapi cara tersebut tampaknya rusak saat ini. Saya tidak suka memiliki kelas pengujian yang memperluas kelas kerangka kerja pengujian, sepertinya hackish.

Jika Anda tidak menggunakan PowerMock, tentu saja ini bukan masalah, tetapi secara keseluruhan saya mendapat kesan bahwa JUnit4 lebih didukung.

Berdasarkan pengalaman saya dengan kedua kerangka kerja, testng memiliki beberapa fitur mudah yang telah ditolak untuk diterapkan oleh tim JUnit selama beberapa tahun. Saya lebih suka JUnit karena alasan ini. Mengonversi ke testng itu mudah karena pada dasarnya mendukung hampir semua yang ada di JUnit (ada plugin konverter bahkan untuk gerhana), mengonversi kembali ke JUnit tidak terlalu bagus karena fitur-fitur yang hilang ini.

• Dalam @BeforeClassmetode pengujian tidak statis dan dijalankan sebelum pengujian di kelas tersebut dijalankan daripada saat kelas pengujian dimuat (perilaku JUnit). Saya pernah memiliki proyek JUnit di mana semua tes database (beberapa lusin) menginisialisasi database tepat di awal, yang merupakan perilaku yang cukup konyol. Ada banyak perdebatan yang mendukung dan menentang hal ini di komunitas JUnit. Intinya adalah bahwa setiap metode pengujian harus memiliki perlengkapan pengujiannya sendiri dan oleh karena itu Anda tidak boleh memiliki metode gaya beforeAll yang non-statis karena itu akan memungkinkan Anda untuk secara diam-diam menetapkan variabel instance sekali dan kemudian menggunakannya dalam semua pengujian Anda. Valid, tetapi sangat mengganggu untuk pengujian integrasi. TestNG memberi pengguna pilihan di sini. Junit tidak, secara sengaja, yang mengganggu.

• Penyedia data pengujian sedikit lebih fleksibel daripada JUnit yang setara. Anda dapat menentukan per pengujian, metode penyedia data mana yang harus menyediakan input daripada memiliki pendekatan satu ukuran yang cocok untuk semua untuk seluruh kelas seperti di JUnit. Jadi, Anda dapat memiliki penyedia data kasus positif dan negatif untuk pengujian Anda di satu kelas. Sangat bagus untuk dimiliki.

• Anda dapat menandai kelas dengan @Testin testng, yang artinya: setiap metode publik adalah pengujian. Di Junit Anda perlu menyalin / menempel @Testdi setiap metode.

Gangguan dengan keduanya adalah cara hamcrest digabungkan dengan JUnit dan cara JUnit digabungkan dengan testng. Ada toples perubahan di maven yang tidak memiliki masalah ini.

Kekhawatiran besar saya dengan kedua kerangka tersebut adalah bahwa keduanya tampaknya telah berhenti berevolusi. Rilis semakin jarang dan cenderung memiliki fitur yang semakin tidak penting. Seluruh gerakan BDD tampaknya berdampak kecil pada salah satu kerangka kerja misalnya. Juga, JUnit bisa saja mengadopsi sebagian besar dari apa yang saya sebutkan di atas. Tidak ada alasan teknis yang baik mengapa JUnit tidak dapat mengimplementasikan hal-hal ini; orang-orang di belakang JUnit memilih untuk tidak menerapkan hal-hal ini. Kedua proyek tersebut tampaknya juga kurang memiliki visi untuk arah masa depan dan mereka tampaknya senang melakukan perubahan kecil selama beberapa tahun terakhir.

Saya sedang mencari alasan bagus untuk mengganti TestNG melalui JUnit dan saya menemukan slide ini oleh Tomek Kaczanowski menjawab pertanyaan ini dengan sangat baik. Tomek adalah penulis buku Pengujian Unit Praktis yang tampaknya sangat dihormati oleh pengembang dan penguji.

Jika Anda mengerjakan proyek Java / Scala dan Gradle adalah alat build pilihan Anda, perlu diingat bahwa ScalaTestframework hanya JUnitRunneruntuk menjalankan pengujian skala Anda. Dengan kata lain, Anda punya pilihan:

• Pengujian JUnit Java + Pengujian Scala dijalankan dengan JUnitRunner => Integrasi Gradle yang lebih baik
• Pengujian testNG Java + Pengujian Scala dijalankan dengan Scala Runner => Integrasi Gradle yang Buruk, karena runner pengujian skala adalah tugas massal tunggal dari sudut pandang Gradle.

Anda dapat menggunakan Mockito sebagai kerangka kerja tiruan Anda. Ini terintegrasi dengan baik dengan TestNG. Anda tidak perlu memperluas kelas apa pun untuk menggunakan Mockito dengan TestNG. Anda menguji kode kurang digabungkan dengan cara ini dan jika karena alasan apa pun Anda perlu menggunakan kerangka kerja tiruan lainnya, mudah untuk melakukannya.

Pendeknya..

Jika cakupan Anda terbatas pada pengujian unit yang mendetail tanpa ketergantungan di antaranya, maka JUnit dapat digunakan.

Jika cakupan Anda memerlukan pengujian fungsional yang mungkin / mungkin tidak memerlukan dependensi dan berbagi data (parameter) di antara pengujian, pilih TestNG. Selain itu, TestNG dapat melakukan pengujian unit yang mirip dengan JUnit. JADI, Anda dapat memiliki serangkaian pengujian unit dan serangkaian pengujian fungsional.