JUnit बनाम TestNG [बंद]


125

वर्तमान में हम अपने परीक्षण चलाने के लिए वर्तमान में JUnit 3 का उपयोग कर रहे हैं। हम नए परीक्षणों के लिए JUnit 4 पर स्विच करने पर विचार कर रहे हैं, लेकिन मैं अभी कुछ समय के लिए TestNG पर नजर रख रहा हूं। JUnit 4 या TestNG के साथ आप सभी को क्या अनुभव हुआ है, और जो बहुत बड़ी संख्या में परीक्षणों के लिए बेहतर काम करता है? लेखन परीक्षणों में लचीलापन होना हमारे लिए भी महत्वपूर्ण है क्योंकि हमारे कार्यात्मक परीक्षण एक व्यापक पहलू को कवर करते हैं और परिणाम प्राप्त करने के लिए विभिन्न तरीकों से लिखे जाने की आवश्यकता होती है।

पुराने परीक्षणों को फिर से नहीं लिखा जाएगा क्योंकि वे अपना काम ठीक करते हैं। मैं नए परीक्षणों में देखना चाहूंगा, हालांकि परीक्षण के लिखे जाने के तरीके में लचीलापन है, प्राकृतिक अभिकथन, समूहीकरण और आसानी से वितरित किए गए परीक्षण निष्पादन।


10
08 से अब तक कोई परिवर्तन ????
some_other_guy

बस उपयोग TestNG, यह सब कुछ है कि Junit है, और बहुत अधिक है!
एरिक वांग

जवाबों:


67

मैंने दोनों का उपयोग किया है, लेकिन मुझे जस्टिन मानक से सहमत होना है कि आप वास्तव में किसी भी नए प्रारूप में अपने मौजूदा परीक्षणों को फिर से लिखने पर विचार न करें। निर्णय के बावजूद, यह दोनों को चलाने के लिए बहुत तुच्छ है। TestNG JUnit की तुलना में बहुत अधिक कॉन्फ़िगर करने का प्रयास करता है, लेकिन अंत में वे दोनों समान रूप से अच्छी तरह से काम करते हैं।

TestNG में एक साफ़ सुथरी सुविधा है जहाँ आप एक विशेष समूह के रूप में परीक्षणों को चिह्नित कर सकते हैं, और फिर किसी विशिष्ट समूह के सभी परीक्षण आसानी से चला सकते हैं, या किसी विशेष समूह के परीक्षणों को बाहर कर सकते हैं। इस प्रकार आप उन परीक्षणों को चिह्नित कर सकते हैं जो "धीमे" समूह के रूप में धीरे-धीरे चलते हैं और फिर जब आप त्वरित परिणाम चाहते हैं तो उन्हें अनदेखा कर सकते हैं। उनके दस्तावेज़ीकरण का एक सुझाव कुछ चेकसेट को "चेकइन" परीक्षणों के रूप में चिह्नित करना है जो कि जब भी आप नई फ़ाइलों की जांच करते हैं, तो उन्हें चलाया जाना चाहिए। मैंने JUnit में ऐसी सुविधा कभी नहीं देखी थी, लेकिन फिर, यदि आपके पास यह नहीं है, तो आप डॉन ' टी वास्तव में यह याद आती है।

उच्च विन्यास के अपने सभी दावों के लिए, मैंने कुछ हफ़्ते पहले एक कोने के मामले में भाग लिया था जहाँ मैं वह नहीं कर सकता था जो मैं करना चाहता था ... काश मैं यह याद रख पाता कि यह क्या है, लेकिन मैं इसे लाना चाहता था। तो आप जानते हैं कि यह सही नहीं है।

TestNG का सबसे बड़ा लाभ एनोटेशन है ... जो कि JUnit ने संस्करण 4 में जोड़ा है।


14
JUnit उस ग्रुपिंग चीज़ को कर सकता है जिसके बारे में आप टेस्ट सूट को परिभाषित करके और फिर उस समूह में वांछित समूह में परीक्षणों को जोड़कर बात कर रहे हैं। फिर आप अपनी चींटी स्क्रिप्ट में एक लक्ष्य सेट कर सकते हैं जो केवल उस सुइट को चलाता है, और चेकइन पर उस लक्ष्य को चलाने के लिए अपने स्रोत नियंत्रण को सेट करता है।
जस्टिन स्टैंडर्ड

8
JUnit पर TestNG का सबसे बड़ा फायदा यह है कि यह पैरामीटर परीक्षण के लिए डायनामिक रूप से परीक्षण डेटा उत्पन्न करने की क्षमता रखता है। प्रत्येक परीक्षण डेटा तत्व एक अलग "परीक्षण" है, इसलिए यह डेटा-संचालित परीक्षण testng.org/doc/documentation-main.html#parameters
davetron5000

6
पैरामीट्रिज्ड टेस्ट थ्योरी के साथ आसान होते हैं, जो कि जूनिट के नए संस्करणों में एकीकृत हैं (लेकिन फिलहाल प्रायोगिक हैं)।
मनेन्थ

9
TestNG समूहों को श्रेणियाँ के साथ JUnit 4.8 में किया जा सकता है: kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
Kaitsu

कुछ बातों का उल्लेख नहीं किया गया है: मुझे लगता है कि TestNG का सबसे अच्छा लाभ उन्हीं मापदंडों को पारित करने में सक्षम हो रहा है जो आपने प्रत्येक परीक्षण विधि में पारित किए, परीक्षण कॉन्फ़िगरेशन विधियों से पहले / बाद में भी: यह सेटअप और फाड़ने में बहुत मदद करता है, IMHO बहुत शक्तिशाली है। यदि आप ऐसा नहीं समझते हैं, तो आप सोच सकते हैं कि आपको इसकी आवश्यकता नहीं है। इसके अलावा, मुझे पसंद है कि आप कोड में टेस्ट सूट को कैसे परिभाषित कर सकते हैं।
djangofan

20

पहले मैं कहूंगा, अपने सभी परीक्षणों को केवल नवीनतम सनक के अनुरूप लिखने के लिए नहीं। Junit3 पूरी तरह से अच्छी तरह से काम करता है, और 4 में एनोटेशन की शुरूआत आपको (मेरी राय में) बहुत ज्यादा नहीं खरीदती है। यह बहुत महत्वपूर्ण है कि आप लोग परीक्षण लिखें , और ऐसा लगता है जैसे आप करते हैं।

जो भी सबसे स्वाभाविक लगता है उसका उपयोग करें और आपको अपना काम पूरा करने में मदद करें।

मैं TestNG पर टिप्पणी नहीं कर सकता b / c मैंने इसका उपयोग नहीं किया है। लेकिन मैं यूनिटिल्स की सिफारिश करूंगा , जो आपके लिए कौन सा मार्ग अपनाएगा, JUnit / TestNG / DBUnit / EasyMock के लिए एक बढ़िया आवरण। (यह ऊपर वर्णित सभी स्वादों का समर्थन करता है)


1
यूनिटल्स ऐसा नहीं लगता है कि इसे थोड़ी देर में अपडेट किया गया है; यह JUnit / TestNG के नए संस्करणों के साथ काम करेगा?
चिनसौर

2011 में इस उत्तर को खोजने वाले किसी भी व्यक्ति के लिए, मैंने जाँच की, और नवीनतम यूनिट्स संस्करण (3.2), की रिलीज़ की तारीख: 2011-09-29 है। तो यह है सक्रिय रूप से बनाए रखा जा रहा।
ओगरे Psalm33

18

मेरे लिए TestNG के सबसे बड़े ड्रॉ कार्ड्स में इसके सपोर्ट टेस्ट ग्रुप शामिल हैं, और इससे भी महत्वपूर्ण बात यह है कि - टेस्ट ग्रुप डिपेंडेंसीज़ (एक टेस्ट को ग्रुप के आश्रित होने के रूप में चिन्हित करना, टेस्ट्स को केवल तभी चलाना छोड़ देता है, जब डिपेंडेंट ग्रुप फेल हो जाता है)।

मेरे लिए TestNG के अन्य बड़े ड्रा कार्ड में परीक्षण पैरामीटर, डेटा प्रदाता, एनोटेशन ट्रांसफार्मर, और कुछ से अधिक - जीवंत और उत्तरदायी उपयोगकर्ता समुदाय शामिल हैं।

जब तक सतह पर किसी को नहीं लगता है कि ऊपर दिए गए सभी TestNGs सुविधाओं की आवश्यकता नहीं हो सकती है, एक बार जब आप लचीलेपन को अपने परीक्षणों के लिए समझना शुरू करते हैं, तो आपको आश्चर्य होगा कि आपने JUnit के साथ कैसे मुकाबला किया।

(अस्वीकरण - मैंने JUnit 4.x का उपयोग बिल्कुल नहीं किया है, इसलिए वास्तव में अग्रिम या नई सुविधाओं पर टिप्पणी करने में असमर्थ हूं)।


3
मैं JUnit4 और TestNG दोनों का उपयोग कर रहा हूं, TestNG को स्प्रिंग स्प्रिंग-टेस्ट एकीकरण के लिए बेहतर समर्थन है। वसंत आधारित अनुप्रयोग का परीक्षण करना बहुत आसान बनाता है।
hidralisk

18

लगभग एक साल पहले, हम एक ही समस्या थी। मैंने कुछ समय बिताया जिसमें यह माना गया कि कौन सा कदम बेहतर था, और आखिरकार हमने महसूस किया कि टेस्टएनजी की कोई 'हत्यारा विशेषताएं' नहीं हैं। यह अच्छा है, और कुछ विशेषताएं हैं JUnit 4 के पास नहीं है, लेकिन हमें उनकी आवश्यकता नहीं है।
हम नहीं चाहते थे कि लोग TestNG को जानने के दौरान असहज लेखन परीक्षण महसूस करें क्योंकि हम चाहते थे कि वे बहुत सारे परीक्षण लिखना जारी रखें।
इसके अलावा, जावा दुनिया में JUnit बहुत वास्तविक मानक है। कोई भी अच्छा उपकरण नहीं है जो इसे बॉक्स से समर्थन नहीं करता है, आप वेब पर बहुत मदद कर सकते हैं और उन्होंने पिछले वर्ष में कई नई सुविधाएँ जोड़ी हैं जो यह बताती हैं कि यह जीवित है।

हमने जुनीत के साथ रहने का फैसला किया और कभी पीछे मुड़कर नहीं देखा।


IMHO, TestNG का किलर फीचर, सेटअप विधियों से पहले और बाद में संदर्भ आर्गन्स पास करने की क्षमता है। आप वहां बहुत सारे जादू के टोटके कर सकते हैं, जो जूनित नहीं कर सकते। 95% लोग TestNG को अच्छी तरह से जानने की जहमत नहीं उठाते हैं और इससे अनभिज्ञ हैं। इसके अलावा, TestNG के पास डेटाप्रॉइडर के माध्यम से थ्रेडिंग का एक अच्छा तरीका है, लेकिन केवल अगर आप इसका लाभ उठाते हैं। इसके अलावा, testng.xml में बीन्सल शामिल हो सकते हैं।
djangofan

17

उपरोक्त सभी को चीयर्स। कुछ अन्य चीजें जो मैंने व्यक्तिगत रूप से पाई हैं, मुझे टेस्टएनजी में अधिक पसंद हैं:

  1. @BeforeClassTestNG के लिए वर्ग निर्माण के बाद जगह लेता है, तो आप केवल उस में अपने वर्ग के स्थिर तरीकों कॉल करने के लिए सक्षम किया जा रहा से विवश नहीं कर रहे हैं।

  2. समानांतर और पैरामीटर किए गए परीक्षण, शायद मेरे पास बस एक जीवन भर नहीं है ... लेकिन मुझे एक सेलेनियम परीक्षणों का एक सेट लिखने के लिए एक किक मिलता है, एक चालक का नाम एक पैरामीटर के रूप में स्वीकार करता है। फिर 3 समानांतर परीक्षण समूहों, आईई, एफएफ और क्रोम ड्राइवरों के लिए प्रत्येक को परिभाषित करना, और दौड़ को देखना! मैंने मूल रूप से 4 किया, लेकिन जिस तरह से मैंने HtmlUnitएक या किसी अन्य कारण से ड्राइवर को तोड़ने का काम किया है उनमें से बहुत सारे पृष्ठ हैं ।

हाँ, शायद उस जीवन को खोजने की जरूरत है। ;)


अंत में कुछ उम्मी टिप्पणी के बाद सभी उम्म वे दोनों समान हैं। और awwhing
user2412398

हाँ, TestNG नियम: मैं TestNG DataProvider से भी परीक्षण आर्ग के माध्यम से ड्राइवर इंस्टेंस को लोड करता हूं। यहाँ मैंने यह कैसे किया: github.com/djangofan/yet-another-selenium-framework/blob/master/…
djangofan

10

मैं आज जो भी सामने आया उसे साझा करना चाहता था। मैंने पाया कि पैरिनेटाइज्ड रनर जूनीट 4 में काफी क्रूड है क्योंकि टेस्टएनजी की तुलना में (मुझे पता है कि हर फ्रेमवर्क की अपनी ताकत है लेकिन फिर भी)। Junit4 एनोटेशन @ पैरामीटर्स मापदंडों के एक सेट तक सीमित है। एक ही परीक्षण वर्ग में कार्यक्षमता के लिए वैध और अमान्य व्यवहार का परीक्षण करते समय मुझे इस समस्या का सामना करना पड़ा। तो पहले सार्वजनिक, स्थिर एनोटेट विधि जो इसे ढूंढती है उसका उपयोग किया जाएगा, लेकिन यह उन्हें किसी भी क्रम में मिल सकता है। यह हमें विभिन्न वर्गों को अनावश्यक रूप से लिखने का कारण बनता है। हालाँकि TestNG प्रत्येक और हर विधि के लिए विभिन्न प्रकार के डेटा प्रदाता प्रदान करने का स्वच्छ तरीका प्रदान करता है। इसलिए हम एक ही टेस्ट क्लास में वैध और अवैध तरीके से कोड की एक ही यूनिट को अलग-अलग वैध / अमान्य डेटा डालकर टेस्ट कर सकते हैं। मैं TestNG के साथ जाऊंगा।


7

इसके अलावा TestNG का एक और लाभ समानांतर परीक्षण का समर्थन कर रहा है। मल्टीकोर्स के हमारे युग में यह महत्वपूर्ण है, मुझे लगता है।

मैंने दोनों चौखटों का भी इस्तेमाल किया। लेकिन मैं जोर देने के लिए हैमरेस्ट का उपयोग कर रहा हूं। Hamcrest आपको आसानी से अपनी खुद की मुखर विधि लिखने की अनुमति देता है। इसलिए इसके बजाय

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

तुम लिख सकते हो

assertThat(operation, isActive());

यह आपको अपने परीक्षणों में उच्च स्तर के अमूर्त का उपयोग करने का अवसर देता है। और यह आपके परीक्षणों को और अधिक मजबूत बनाता है।


7

JUnit 4 Vs TestNG - mkyong.com द्वारा तुलना (2013 को अद्यतन)।

निष्कर्ष: मैं जावा प्रोजेक्ट के लिए TestNG को कोर यूनिट टेस्ट फ्रेमवर्क के रूप में उपयोग करने का सुझाव देता हूं, क्योंकि TestNG अधिक है परीक्षण, निर्भरता परीक्षण और सूट परीक्षण (ग्रुपिंग कॉन्सेप्ट) के पैरामीटर में अग्रिम है।

TestNG कार्यात्मक, उच्च-स्तरीय परीक्षण और जटिल एकीकरण परीक्षण के लिए है। इसका लचीलापन विशेष रूप से बड़े परीक्षण सूट के साथ उपयोगी है।

इसके अलावा, TestNG पूरे कोर JUnit4 कार्यक्षमता को भी कवर करता है । यह मेरे लिए अब JUnit का उपयोग करने का कोई कारण नहीं है।

सरल शब्दों में, TestNG = JUnit + बहुत अधिक। तो, बहस क्यों? जाओ और TestNG को पकड़ो :-)

आप यहां अधिक विस्तृत तुलना पा सकते हैं ।


5

माइक स्टोन के जवाब में कुछ जोड़:

1) जब मैं एक परीक्षण सूट में एक ही परीक्षण विधि चलाना चाहता हूं, तो सबसे अधिक बार मैं टेस्टनेग के समूहों का उपयोग करता हूं। मैं बस इस परीक्षण को "फिल" समूह में जोड़ता हूं और फिर इस समूह को चलाता हूं। जब मैं JUnit 3 का उपयोग कर रहा था, तो मैं सभी विधियों के लिए प्रविष्टियों की टिप्पणी करूंगा, लेकिन जो मैं "सूट" विधि में चलाना चाहता था, लेकिन फिर चेकइन से पहले उन्हें अनसुना करना भूल जाएगा। समूहों के साथ, मुझे अब यह समस्या नहीं है।

2) परीक्षणों की जटिलता के आधार पर, JUnit3 से TestNG के लिए माइग्रेट किए गए परीक्षण स्वचालित रूप से कुछ हद तक sed के साथ किए जा सकते हैं और TestCase को बदलने के लिए एक बेस क्लास बना सकते हैं, जो सभी TestNG के तरीकों का स्थैतिक आयात करता है।

मैं TestNG को JUnit से मेरे प्रवास पर जानकारी है यहाँ और यहाँ


आपके द्वारा किए गए परिवर्तनों में जाँच की समस्या वास्तविक नहीं है क्योंकि आपको समीक्षा करनी है कि आप किस चीज़ की जाँच कर रहे हैं। और यदि आपके पास एक बड़ी जाँच है, तो यह कोई बहाना नहीं है, यह एक और समस्या है: आपको कई छोटे जाँच करने चाहिए।
हिडलिस्क

5

क्यों हम JUnit के बजाय TestNG का उपयोग करते हैं?

  1. की घोषणा @BeforeClassऔर @AfterClassविधि को JUnit में स्थिर होना पड़ता है, जबकि विधि घोषणा में TestNG में अधिक लचीलापन होता है, इसमें ये बाधाएँ नहीं होती हैं।

  2. TestNG में, हम 2 तरीकों का उपयोग करके परीक्षण कर सकते हैं । @ पैरामीटर या @DataProvider एनोटेशन।

    i) @ सरल मामलों के लिए पैरामीटर , जहां कुंजी मान मानचित्रण आवश्यक है। (डेटा xml फ़ाइल के माध्यम से प्रदान किया गया है)

    ii) जटिल मामलों के लिए @DataProvider । 2 आयामी सरणी का उपयोग करना, यह डेटा प्रदान कर सकता है।

  3. TestNG में, चूंकि @DataProvider विधि को स्थिर होने की आवश्यकता नहीं है, हम एक ही परीक्षण वर्ग में कई डेटा प्रदाता विधियों का उपयोग कर सकते हैं।

  4. निर्भरता परीक्षण: TestNG में, यदि प्रारंभिक परीक्षण विफल हो जाता है, तो बाद के सभी आश्रित परीक्षण छोड़ दिए जाएंगे, असफल के रूप में चिह्नित नहीं किया जाएगा। लेकिन JUnit ने कहा कि यह विफल रहा।

  5. समूहीकरण: एकल परीक्षण कई समूहों से संबंधित हो सकते हैं और फिर विभिन्न संदर्भों (जैसे धीमी या तेज़ परीक्षा) में चलते हैं। एक समान सुविधा JUnit श्रेणियों में मौजूद है, लेकिन @BeforeGroups / @AfterGroups TestNG एनोटेशन का अभाव है जो परीक्षण को प्रारंभ करने / इसे फाड़ने की अनुमति देता है।

  6. समानांतरवाद: यदि आप एक ही परीक्षा को कई थ्रेड्स पर समानांतर में चलाना चाहते हैं, तो TestNG ने आपको एनोटेशन का उपयोग करने के लिए एक सरल के साथ कवर किया है, जबकि JUnit बॉक्स से बाहर ऐसा करने का एक सरल तरीका प्रदान नहीं करता है।

  7. TestNG @DataProvider डेटा में फीडिंग के लिए XML, CSV या यहां तक ​​कि सादे पाठ फ़ाइलों का भी समर्थन कर सकता है।

  8. TestNG आपको परीक्षणों के बीच निर्भरता की घोषणा करने की अनुमति देता है, और अगर निर्भरता परीक्षा पास नहीं हुई तो उन्हें छोड़ दें।

@ टेस्ट (निर्भरऑनमेथोड्स = {"निर्भरऑनसेटिंग"})

यह कार्यक्षमता JUnit में मौजूद नहीं है

  1. रिपोर्टिंग:

TestNG रिपोर्ट डिफ़ॉल्ट रूप से एक परीक्षण-आउटपुट फ़ोल्डर में उत्पन्न होती है, जिसमें सभी परीक्षण डेटा के साथ HTML रिपोर्टें शामिल होती हैं, पारित / विफल / छोड़ दिया गया, वे कितने समय तक चले, किस इनपुट का उपयोग किया गया और पूर्ण परीक्षण लॉग। इसके अलावा, यह एक XML फ़ाइल के लिए भी सब कुछ निर्यात करता है जिसका उपयोग आपके स्वयं के रिपोर्ट टेम्पलेट के निर्माण के लिए किया जा सकता है।

JUnit के मोर्चे पर, यह सारा डेटा XML के माध्यम से भी उपलब्ध है, लेकिन बॉक्स रिपोर्ट से बाहर नहीं है और आपको प्लगइन्स पर भरोसा करने की आवश्यकता है।

संसाधन लिंक:

  1. एक त्वरित JUnit बनाम TestNG तुलना
  2. JUnit बनाम TestNG: आपको कौन सा परीक्षण ढांचा चुनना चाहिए?

इस ट्यूटोरियल साइड में एक अच्छा अंतर दिया गया है: TestNG Vs JUnit: क्या अंतर है?


आपने TestNG की सबसे विशिष्ट विशेषता IHMO को सूचीबद्ध नहीं किया: संदर्भ पास करने की क्षमता पहले और बाद के तरीकों में आ जाती है, जो आपको कुछ जादू करने में सक्षम बनाती है। DataProvider इस तरह से एक उदाहरण के रूप में काम करता है।
djangofan

3

आपके प्रश्न से मुझे दो प्रश्न लगते हैं। एक पर आप दो परीक्षण रूपरेखाओं की तुलना करना चाहेंगे, दूसरी ओर आप आसानी से परीक्षण लागू करना चाहते हैं, प्राकृतिक दावे आदि हैं ...

ठीक है, सबसे पहले JUnit कार्यक्षमता के मामले में TestNG के साथ कैचअप खेल रहा है, उन्होंने v4 के साथ कुछ अंतर को पाटा है, लेकिन मेरी राय में यह पर्याप्त नहीं है। TestNG में एनोटेशन और डेटाप्रॉइडर्स जैसी चीजें अभी भी बहुत बेहतर हैं। टेस्ट निष्पादन के मामले में भी वे अधिक लचीले हैं, क्योंकि टेस्टएनजी में टेस्ट डिपेंडेंसी, ग्रुपिंग और ऑर्डरिंग है।

JUnit को स्टैटिक होने के लिए अभी भी पहले / बाद के तरीकों की आवश्यकता है, जो कि आप परीक्षणों के चलने से पहले क्या कर सकते हैं, TestNG में यह समस्या कभी नहीं होती है।

जब तक आपका एकीकरण / स्वचालन परीक्षण पर ध्यान केंद्रित नहीं किया जाता है, तब तक टीबीएच, ज्यादातर दो रूपरेखाओं के बीच अंतर ज्यादा मायने नहीं रखता है। मेरे अनुभव से JUnit को यूनिट परीक्षण के लिए जमीन से बनाया गया है और अब परीक्षण के उच्च स्तर की ओर धकेला जा रहा है, जो IMO इसे नौकरी के लिए गलत उपकरण बनाता है। TestNG इकाई परीक्षण में अच्छी तरह से करता है और इसकी मजबूत डेटाप्रॉइडिंग और महान परीक्षण निष्पादन क्षमताओं के कारण, एकीकरण / स्वचालन परीक्षण स्तर पर भी बेहतर काम करता है।

अब मेरा मानना ​​है कि एक अलग मुद्दा है, कैसे अच्छी तरह से संरचित, पठनीय और बनाए रखने योग्य परीक्षण लिखने के लिए। इसमें से अधिकांश मुझे यकीन है कि आप जानते हैं, लेकिन फैक्ट्री पैटर्न , कमांड पैटर्न और पेजऑब्जेक्ट्स (यदि आपकी परीक्षण वेबसाइटें) जैसी चीजें महत्वपूर्ण हैं, तो आपके परीक्षण (SUT) और वास्तविक परीक्षण के बीच अमूर्तता की एक परत होना बहुत महत्वपूर्ण है। है (व्यापार तर्क का दावा)। बहुत अच्छे दावे करने के लिए, आप Hamcrest का उपयोग कर सकते हैं । पुनरावृत्ति को कम करने और समानता को लागू करने के लिए जावा विरासत / इंटरफेस का उपयोग करें।

लगभग भूल गए, टेस्ट डेटा बिल्डर पैटर्न का भी उपयोग करें , TestNG के डेटाप्रोइडर एनोटेशन के साथ युग्मित यह बहुत उपयोगी है।


3

TestNG वास्तव में कहीं अधिक शक्तिशाली बनाता है के बारे में मेरी राय:

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.
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.