JUnit 4 - TestNG - Güncelleme 2013 - 2014 [kapalı]

JUnit 4 ve TestNG karşılaştırılabilirdi. İki test çerçevesinin artıları ve eksileri nelerdir?

Bugün TestNG ve JUnit4'ü karşılaştırıyordum ve test çerçevelerindeki sınırlı deneyimimle belirtebileceğim ana avantaj, TestNG'nin veri sağlayıcı konseptiyle parametrize testleri daha zarif bir şekilde ele almasıdır.

JUnit4 ile söyleyebileceğim kadarıyla, test etmek istediğiniz her parametre seti için ayrı bir test sınıfı oluşturmalısınız (birlikte koştu @RunWith(Parameterized.class)). TestNG ile tek bir test sınıfında birden fazla veri sağlayıcısına sahip olabilirsiniz, böylece tek bir sınıftaki tüm testlerinizi tek bir test sınıfında da tutabilirsiniz.

Şimdiye kadar TestNG'nin JUnit4'e olan faydası olarak gösterebileceğim tek şey bu.

Intellij IDEA, kutudan çıkar çıkmaz TestNG ve JUnit desteği içerir. Bununla birlikte, Eclipse yalnızca JUnit'i kutudan çıkarır ve çalışmasını sağlamak için bir TestNG eklentisine ihtiyaç duyar.

Bununla birlikte, TestNG ile karşılaştığım daha can sıkıcı bir sorun PowerMockTestCase, testlerinizde bağımlılıklarla dalga geçmek için PowerMock kullanıyorsanız , test sınıflarınızın genişletilmesi gerektiğidir. Görünüşe göre, test çerçevenizin PowerMock'u özel bir yöntemle veya özel bir yöntemle kullanırken bilmesi gereken nesne fabrikasını yapılandırmanın yolları var.testng.xml paket tanımı , ancak bunlar şu anda bozuk görünüyor. Test sınıflarının test çerçevesi sınıflarını genişletmesinden hoşlanmıyorum, hile gibi görünüyor.

PowerMock kullanmazsanız, bu elbette bir sorun değildir, ancak sonuçta JUnit4'ün daha iyi desteklendiği izlenimini edindim.

Her iki çerçeveyle ilgili deneyimime dayanarak, testng, JUnit ekibinin birkaç yıldır uygulamayı reddettiği birkaç kullanışlı özelliğe sahiptir. Bu nedenle JUnit'e tercih ediyorum. Temelde JUnit'te hemen hemen her şeyi desteklediği için (tutulma için bir dönüştürücü eklentisi var) testng'ye dönüştürmek kolaydır, JUnit'e geri dönüştürmek bu eksik özellikler nedeniyle o kadar da iyi değildir.

• Testng'de @BeforeClassyöntemler statik değildir ve test sınıfı yüklendiğinde değil, o sınıftaki testler çalıştırılmadan önce yürütülür (JUnit davranışı). Bir zamanlar tüm veritabanı testlerinin (birkaç düzine) veritabanını en baştan başlattığı, oldukça aptalca bir davranış olan bir JUnit projem vardı. JUnit topluluğunda bunun lehinde ve aleyhinde birçok tartışma vardı. İşin özü, her test yönteminin kendi test fikstürüne sahip olması gerektiğiydi ve bu nedenle, statik olmayan bir beforeAll stili yöntemine sahip olmamalısınız çünkü bu, bir kez sinsice bir örnek değişkeni ayarlamanıza ve ardından bunu tüm testlerinizde kullanmanıza olanak tanır. Geçerli, ancak entegrasyon testleri için gerçekten can sıkıcı. TestNG, kullanıcılara burada seçenek sunar. Tasarım gereği can sıkıcı olan Junit bunu yapmaz.

• Test veri sağlayıcıları, JUnit eşdeğerinden biraz daha esnektir. JUnit'te olduğu gibi tüm sınıf için herkese uyan tek bir yaklaşıma sahip olmak yerine, hangi veri sağlayıcı yönteminin girdiyi sağlaması gerektiğini test başına belirtebilirsiniz. Böylece tek bir sınıfta testleriniz için pozitif ve negatif vaka veri sağlayıcılarına sahip olabilirsiniz. Sahip olmak çok güzel.

• @TestIn testng ile bir sınıfı işaretleyebilirsiniz , bu şu anlama gelir: her genel yöntem bir testtir. Junit'te @Testher yöntemi kopyalamanız / yapıştırmanız gerekir .

Her ikisinde de bir rahatsızlık, hamcrest'in JUnit ile paketlenme şekli ve JUnit'in test ile paketlenme şeklidir. Maven'de bu sorunu olmayan alterate kavanozlar var.

Her iki çerçeveyle ilgili en büyük endişem, ikisinin de gelişmeyi bırakmış gibi görünmesidir. Sürümler giderek daha az sıklıkta ve giderek daha az dikkate değer özelliklere sahip olma eğilimindedir. Örneğin BDD hareketinin tamamı her iki çerçeve üzerinde de çok az etkiye sahip görünüyor. Ayrıca, JUnit yukarıda listelediklerimin çoğunu benimsemiş olabilir. JUnit'in bunlardan herhangi birini uygulayamaması için iyi bir teknik neden yoktur; JUnit'in arkasındaki insanlar sadece bunları uygulamamayı seçerler. Her iki proje de gelecekteki yönler için bir vizyondan yoksun görünüyor ve son birkaç yıldır sadece küçük değişiklikler yapmaktan mutlu görünüyorlar.

Ben JUnit üzerinde TestNG geçmek için iyi bir nedenden arıyordu ve ben buldum bu çok iyi bu soruyu ele Tomek Kaczanowski tarafından slaytlar. Tomek, geliştiriciler ve testçiler tarafından çok saygı duyulan Practical Unit Testing kitabının yazarıdır .

Java / Scala projesi üzerinde çalışıyorsanız ve Gradle sizin tercih ettiğiniz derleme aracıysa, ScalaTestframework'ün yalnızca JUnitRunnerscala testlerinizi çalıştırması gerektiğini unutmayın. Başka bir deyişle, bir seçeneğiniz var:

• Java JUnit testleri + JUnitRunner ile çalışan Scala Testleri => Daha iyi Gradle entegrasyonu
• Java testiNG testleri + Scala Testleri, Scala Runner ile çalıştırılır => Zayıf Gradle Entegrasyonu, çünkü scala test çalıştırıcısı Gradle'ın bakış açısından tek bir toplu görevdir.

Mockito'yu alay çerçeveniz olarak kullanabilirsiniz. TestNG ile güzel bir şekilde bütünleşir. Mockito'yu TestNG ile kullanmak için herhangi bir sınıfı genişletmeniz gerekmez. Kodu test etmeniz bu şekilde daha az bağlanır ve herhangi bir nedenle diğer alaycı çerçeveleri kullanmanız gerekirse, bunu yapmak kolaydır.

Kısaca..

Kapsamınız aralarında hiçbir bağımlılık bulunmayan ince ayrıntılı birim testleriyle sınırlıysa, JUnit kullanılabilir.

Kapsamınız, bağımlılıklar ve testler arasında veri (parametreler) paylaşımını gerektirebilecek / gerektirmeyebilecek işlevsel test gerektiriyorsa, TestNG'yi seçin. Ayrıca TestNG, JUnit'e benzer birim testleri yapabilir. Böylece bir takım birim testlerine ve bir dizi işlevsel teste sahip olabilirsiniz.