JUnit - TestNG [kapalı]

Şu anda testlerimizi yürütmek için halen JUnit 3 kullanıyoruz. Yazılan yeni testler için JUnit 4'e geçmeyi düşünüyorduk, ancak bir süredir TestNG'ye göz kulak oluyorum. JUnit 4 veya TestNG ile ne tür deneyimler yaşadınız ve hangisi çok sayıda test için daha iyi görünüyor? Testleri yazmada esnekliğe sahip olmak da bizim için önemlidir, çünkü fonksiyonel testlerimiz geniş bir alanı kapsar ve sonuç almak için çeşitli şekillerde yazılması gerekir.

İşlerini iyi yaptıkları için eski testler yeniden yazılmayacaktır. Yine de yeni testlerde görmek istediğim şey, testin yazılma biçiminde esneklik, doğal iddialar, gruplama ve kolayca dağıtılmış test yürütmeleridir.

Her ikisini de kullandım, ancak mevcut testlerinizi herhangi bir yeni formatta yeniden yazmayı gerçekten düşünmemeniz gerektiği konusunda Justin Standard'a katılıyorum. Karar ne olursa olsun, ikisini birden yürütmek oldukça önemsizdir. TestNG, JUnit'ten çok daha yapılandırılabilir olmaya çalışır, ancak sonunda ikisi de eşit derecede iyi çalışır.

TestNG, testleri belirli bir grup olarak işaretleyebileceğiniz ve ardından belirli bir grubun tüm testlerini kolayca çalıştırabileceğiniz veya belirli bir grubun testlerini hariç tutabileceğiniz temiz bir özelliğe sahiptir. Böylece, yavaş çalışan testleri "yavaş" grupta olduğu gibi işaretleyebilir ve hızlı sonuç almak istediğinizde bunları göz ardı edebilirsiniz. Belgelerinden bir öneri, bazı alt kümeleri yeni dosyalar teslim ettiğinizde çalıştırılması gereken "check-in" testleri olarak işaretlemektir. JUnit'te böyle bir özelliği hiç görmedim, ama yine de, eğer sahip değilseniz, yapmazsınız. GERÇEKTEN özlüyorum.

Tüm yüksek konfigürasyon iddialarına rağmen, birkaç hafta önce yapmak istediğimi yapamadığım bir köşe davasıyla karşılaştım ... Keşke ne olduğunu hatırlayabilseydim, ama bunu gündeme getirmek istedim yani mükemmel olmadığını biliyorsunuz.

TestNG'nin sahip olduğu en büyük avantaj, JUnit'in 4. sürümde zaten eklediği ek açıklamalar.

Öncelikle şunu söyleyebilirim, tüm testlerinizi sadece son moda uyacak şekilde yeniden yazmayın. Junit3 mükemmel bir şekilde çalışıyor ve 4'te ek açıklamaların eklenmesi sizi çok fazla satın almıyor (bence). Testler yazmanız çok daha önemli ve kulağa yaptığınız gibi geliyor.

En doğal görünen ve işinizi yapmanıza yardımcı olan şeyi kullanın.

TestNG hakkında yorum yapamam b / c Kullanmadım. Ancak , hangi yolu seçerseniz seçin, JUnit / TestNG / DBUnit / EasyMock için harika bir sarmalayıcı olan unitils'i tavsiye ederim . (Yukarıda belirtilen tüm tatları destekler)

TestNG'nin benim için en büyük çekiliş kartları, destek test gruplarını ve daha da önemlisi - test grubu bağımlılıklarını içerir (bir testi bir gruba bağımlı olarak işaretlemek, bağımlı grup başarısız olduğunda testlerin basitçe çalışmayı atlamasına neden olur).

TestNG'nin benim için diğer büyük çekiliş kartları arasında test parametreleri, veri sağlayıcıları, açıklama dönüştürücüleri ve her şeyden çok daha fazlası var - canlı ve duyarlı kullanıcı topluluğu.

Yüzeyde, yukarıdaki tüm TestNG özelliklerinin gerekli olmayabileceğini düşünebilirsiniz, ancak testlerinize getirdiği esnekliği anlamaya başladığınızda, JUnit ile nasıl başa çıktığınızı merak edeceksiniz.

(feragatname - JUnit 4.x'i hiç kullanmadım, bu yüzden buradaki gelişmeler veya yeni özellikler hakkında gerçekten yorum yapamıyorum).

Yaklaşık bir yıl önce aynı sorunu yaşadık. Bir süre hangi hareketin daha iyi olduğunu düşünerek harcadım ve sonunda TestNG'nin 'öldürücü özellikleri' olmadığını fark ettik. Güzel ve JUnit 4'ün sahip olmadığı bazı özelliklere sahip, ancak onlara ihtiyacımız yok.
İnsanların TestNG'yi öğrenirken test yazma konusunda rahatsız olmalarını istemedik çünkü çok sayıda test yazmaya devam etmelerini istedik.
Ayrıca JUnit, Java dünyasında hemen hemen fiili bir standarttır. Kutudan desteklemeyen düzgün bir araç yok, web'de pek çok yardım bulabilirsiniz ve geçen yıl hayatta olduğunu gösteren birçok yeni özellik eklediler.

JUnit'e bağlı kalmaya karar verdik ve asla geriye bakmadık.

Yukarıdakilerin hepsine şerefe. Şahsen TestNG'de daha çok sevdiğimi bulduğum diğer şeyler:

1. @BeforeClassYalnızca bununla da sınıfın statik yöntemleri çağırmak mümkün kısıtlı değildir bu yüzden TestNG için, sınıf oluşturulduktan sonra gerçekleşir.

2. Paralel ve parametreleştirilmiş testler, belki yeterince hayatım yok ... ama sadece bir set Selenium testi yazıp, bir sürücü adını parametre olarak kabul ederek bir tekme alıyorum. Ardından IE, FF ve Chrome sürücüleri için birer tane olmak üzere 3 paralel test grubu tanımlayın ve yarışı izleyin! Başlangıçta 4 yaptım, ancak üzerinde çalıştığım sayfaların birçoğu, HtmlUnitbir nedenden ötürü sürücüyü kırdı .

Evet, muhtemelen o hayatı bulmalıyız. ;)

Bugün karşılaştığım şeyi paylaşmak istedim. Junit4'te TestNG ile karşılaştırıldığında yerleşik Parameterized runner'ın oldukça kaba olduğunu buldum (Her çerçevenin güçlü yönleri olduğunu biliyorum ama yine de). Junit4 ek açıklaması @parameters bir parametre setiyle sınırlıdır. Aynı test sınıfında işlevsellik için geçerli ve geçersiz davranışı test ederken bu sorunla karşılaştım. Dolayısıyla bulduğu ilk genel, statik açıklamalı yöntem kullanılacak, ancak bunları herhangi bir sırayla bulabilir. Bu da gereksiz yere farklı sınıflar yazmamıza neden oluyor. Ancak TestNG, her yöntem için farklı türde veri sağlayıcıları sağlamanın temiz bir yolunu sağlar. Böylece aynı kod birimini geçerli ve geçersiz bir şekilde aynı test sınıfında geçerli / geçersiz verileri ayrı ayrı koyarak test edebiliriz. TestNG ile gideceğim.

Ayrıca TestNG'nin bir başka avantajı da paralel testi desteklemesidir. Çok çekirdekli çağımızda önemli olduğunu düşünüyorum.

Her iki çerçeveyi de kullandım. Ama iddialar için hamcrest kullanıyorum. Hamcrest, kendi iddia yönteminizi kolayca yazmanıza olanak tanır. Yani yerine

assertEquals(operation.getStatus(), Operation.Status.Active);

Yazabilirsin

assertThat(operation, isActive());

Bu size testlerinizde daha yüksek düzeyde soyutlama kullanma fırsatı verir. Bu da testlerinizi daha sağlam hale getirir.

JUnit 4 Vs TestNG - mkyong.com tarafından karşılaştırma (2013'te güncellendi).

Sonuç: TestNG çünkü Java projesi için çekirdek birim test çerçeve olarak TestNG kullanmayı önermek daha parametrelerle ifade testi, bağımlılık testi ve süit testi (gruplandırma kavram) içinde peşin.

TestNG, işlevsel, üst düzey testler ve karmaşık entegrasyon testi içindir. Esnekliği, özellikle büyük test takımlarında kullanışlıdır.

Ek olarak, TestNG ayrıca tüm temel JUnit4 işlevselliğini kapsar . Artık JUnit kullanmam için bir neden yok.

Basit bir ifadeyle, TestNG = JUnit + çok daha fazlası. Peki neden tartışma? git ve TestNG :-) kap

Daha ayrıntılı karşılaştırmayı burada bulabilirsiniz .

Mike Stone'un cevabına birkaç ekleme:

1) TestNG gruplarını en sık kullandığım şey, bir test paketinde tek bir test yöntemi çalıştırmak istediğim zamandır. Ben sadece bu testi "phil" grubuna ekliyorum ve sonra bu grubu çalıştırıyorum. JUnit 3'ü kullandığımda, "süit" yönteminde çalıştırmak istediğim yöntem dışındaki tüm yöntemler için girişleri yorumluyordum, ancak daha sonra genellikle kontrol etmeden önce açıklamalarını kaldırmayı unuturdum. Gruplarla artık bu sorunu yaşamıyorum.

2) Testlerin karmaşıklığına bağlı olarak, testlerin JUnit3'ten TestNG'ye geçişi, sed ile bir şekilde otomatik olarak yapılabilir ve TestCase'in yerini alacak ve tüm TestNG iddia yöntemlerini statik olarak içe aktaran bir temel sınıf oluşturabilir.

Burada JUnit'ten TestNG'ye geçişimle ilgili bilgilerim var ve burada var .

Neden JUnit yerine TestNG kullanıyoruz?

1. Beyanı @BeforeClass ve @AfterClassyöntemi JUnit'te statik olmalıdır, oysa TestNG'de yöntem bildiriminde daha fazla esneklik vardır, bu kısıtlamalara sahip değildir.

2. TestNG'de testleri 2 yolla parametrize edebiliriz . @Parameter veya @DataProvider ek açıklaması.

   i) @Parameter Anahtar değer eşlemesinin gerekli olduğu basit durumlar için . (veriler xml dosyası aracılığıyla sağlanır)

   ii) Karmaşık durumlar için @DataProvider . 2 boyutlu dizi kullanarak, veri sağlayabilir.

3. TestNG'de @DataProvider yönteminin statik olması gerekmediğinden, aynı test sınıfında birden fazla veri sağlayıcı yöntemi kullanabiliriz.

4. Bağımlılık Testi: TestNG'de, ilk test başarısız olursa, sonraki tüm bağımlı testler atlanacak ve başarısız olarak işaretlenmeyecektir. Ancak JUnit başarısız olduğunu belirtti.

5. Gruplama: Tek testler birden fazla gruba ait olabilir ve ardından farklı bağlamlarda çalıştırılabilir (yavaş veya hızlı testler gibi). JUnit Kategorileri'nde benzer bir özellik mevcuttur, ancak testi başlatmaya / yırtmaya izin veren @BeforeGroups / @AfterGroups TestNG ek açıklamalarına sahip değildir.

6. Paralellik: Aynı testi birden fazla iş parçacığı üzerinde paralel olarak çalıştırmak istiyorsanız, TestNG size kullanımı kolay bir açıklama sunarken, JUnit bunu kutudan çıkarmanın basit bir yolunu sunmuyor.

7. TestNG @DataProvider ayrıca verileri, CSV'leri ve hatta düz metin dosyalarını beslemek için XML'i destekleyebilir.

8. TestNG, testler arasında bağımlılıkları bildirmenize ve bağımlılık testi başarısız olursa atlamanıza olanak tanır.

@Test (bağlıdırOnMethods = {"dependOnSomething"})

Bu işlevsellik JUnit'te mevcut değil

9. Raporlama:

TestNG raporları, varsayılan olarak, tüm test verilerini, geçti / kaldı / atlanan, ne kadar süreyle çalıştırıldığını, hangi girdinin kullanıldığını ve eksiksiz test günlüklerini içeren HTML raporlarını içeren bir test-çıktı klasöründe oluşturulur. Ek olarak, her şeyi kendi rapor şablonunuzu oluşturmak için kullanabileceğiniz bir XML dosyasına aktarır.

JUnit cephesinde, tüm bu verilere XML yoluyla da ulaşılabilir, ancak kullanıma hazır rapor yoktur ve eklentilere güvenmeniz gerekir.

Kaynak Bağlantısı:

1. Hızlı JUnit ve TestNG Karşılaştırması
2. JUnit vs. TestNG: Hangi Test Çerçevesini Seçmelisiniz?

Bu eğitimde yan yana iyi bir fark verilmiştir: TestNG Vs JUnit: Fark Nedir?

Sorunuz bana iki katlı görünüyor. Birinde iki test çerçevesini karşılaştırmak istersiniz, diğer yandan testleri kolayca uygulamak, doğal iddialara sahip olmak vb.

Tamam, öncelikle JUnit işlevsellik açısından TestNG ile yakalama oynuyor, v4 ile bazı boşlukları kapattılar, ancak bence yeterince iyi değil. Ek açıklamalar ve veri sağlayıcıları gibi şeyler TestNG'de hala çok daha iyi. Ayrıca, TestNG'nin test bağımlılığı, gruplaması ve sıralaması olduğundan test yürütme açısından daha esnektirler.

JUnit hala bazı öncesi / sonrası yöntemlerinin statik olmasını gerektirir, bu da testlerin çalıştırılmasından önce yapabileceklerinizi sınırlar, TestNG'de bu sorun hiçbir zaman olmaz.

TBH, çoğunlukla iki çerçeve arasındaki farklar, entegrasyon / otomasyon testine odaklanmadığınız sürece pek bir şey ifade etmez. Deneyimlerime göre JUnit, birim testi için sıfırdan inşa edildi ve şimdi daha yüksek test seviyelerine doğru itiliyor, bu da IMO onu iş için yanlış araç yapıyor. TestNG, birim testlerinde başarılıdır ve sağlam veri sağlama ve mükemmel test yürütme yetenekleri sayesinde entegrasyon / otomasyon testi seviyesinde daha da iyi çalışır.

Şimdi ayrı bir konu olduğuna inandığım şey için, iyi yapılandırılmış, okunabilir ve sürdürülebilir testlerin nasıl yazılacağı. Bunların çoğunu bildiğinize eminim, ancak Factory Pattern , Command Pattern ve PageObjects gibi şeyler (test web siteleriniz varsa) hayati öneme sahiptir, testiniz (SUT) ile gerçek test arasında bir soyutlama katmanına sahip olmak çok önemlidir. (iş mantığının iddiaları). Daha güzel iddialara sahip olmak için Hamcrest'i kullanabilirsiniz . Tekrarı azaltmak ve ortaklığı güçlendirmek için javas kalıtım / arayüzlerinden yararlanın.

Neredeyse unuttum, ayrıca Test Verisi Oluşturucu Modelini de kullanın; bu, TestNG'nin veri sağlayıcı ek açıklamasıyla birleştiğinde çok yararlıdır.

TestNG'yi gerçekten çok daha güçlü yapan şey hakkındaki fikrim:

1.  JUnit still requires the before/after class methods to be static, which limits
    what you can do prior to the running of tests, TestNG never has this issue.

2.  TestNG @Configuration methods can all take an optional argument to their 
    annotated methods in the form of a ITestResult, XmlTest, Method, or 
    ITestContext.  This allows you to pass things around that JUnit wouldn't 
    provide you.  JUnit only does this in listeners and it is limited in use.

3.  TestNG comes with some pre-made report generation classes that you can copy
     and edit and make into your own beautiful test output with very little 
     effort. Just copy the report class into your project and add a listener 
     to run it.  Also, ReportNG is available.

4.  TestNG has a handful of nice listeners that you can hook onto so you can do
     additional AOP style magic at certain phases during testing.