CodeGym /Java Blog /अनियमित /JUnit के साथ जावा में यूनिट परीक्षण
John Squirrels
स्तर 41
San Francisco

JUnit के साथ जावा में यूनिट परीक्षण

अनियमित ग्रुप में प्रकाशित

जावा में यूनिट परीक्षण क्या है?

इससे पहले कि हम जावा में जुनीट सीखें, आइए संक्षेप में अवलोकन करें कि यूनिट परीक्षण क्या है और यह इतना लोकप्रिय क्यों है (यदि आप पहले से ही इस सामग्री को जानते हैं, तो 'मैं जावा में जुनीट टेस्ट कैसे लिख सकता हूं?' पर जाएं)। जावा में यूनिट परीक्षण बड़े पैमाने पर सॉफ्टवेयर विकास को और अधिक कुशल और सहज बनाता है। यह दोनों व्यक्तियों और टीमों को डिबगिंग के अनगिनत घंटों में कटौती करने और सहयोग प्रक्रिया को अत्यधिक कारगर बनाने में मदद कर सकता है। JUnit के साथ Java में यूनिट टेस्टिंग - 1

https://junit.org/junit4/

इकाई परीक्षण का आवश्यक विचार यह है: व्यक्तिगत विशेषताओं के परमाणु परीक्षण लिखें (जिन्हें इकाई परीक्षण कहा जाता है) और धीरे-धीरे परीक्षण के बाद और अधिक सुविधाएँ जोड़ें और सुनिश्चित करें कि पिछले वाले काम करते हैं। यह एक अत्यंत सरल लेकिन शक्तिशाली विचार है। यह प्रक्रिया कैसी दिख सकती है, इसके उदाहरण के रूप में, कल्पना कीजिए कि आप एक आभासी वैज्ञानिक कैलकुलेटर बना रहे हैं। स्पष्ट अंकगणितीय ऑपरेटरों ( +, -, x, %) के शीर्ष पर, इस कैलकुलेटर में उन्नत विशेषताएं होंगी जिनके लिए अन्य उप-सुविधाओं को इसके भीतर काम करने की आवश्यकता होती है। घातांकों की गणना करने के लिए, आपके कैलकुलेटर को सही ढंग से गुणा करने में सक्षम होना चाहिए। तो इस कैलकुलेटर के निर्माण और परीक्षण के लिए एक इकाई परीक्षण दृष्टिकोण होगा:
  • एक अतिरिक्त कार्य लिखें। इसे ध्यान से जांचें, इसे बदलें, जब तक यह काम न करे तब तक दोहराएं।
  • घटाव, गुणा, भाग कार्यों के लिए भी ऐसा ही करें।
  • एक्सपोनेंट जैसे अधिक उन्नत ऑपरेटर कार्यों को लिखने के लिए इन आधार ऑपरेटरों का उपयोग करें, फिर उन कार्यों का भी परीक्षण करें।
यह सुनिश्चित करता है कि अन्य छोटी उप-सुविधाएँ निर्मित करने वाली सुविधाएँ न केवल अपने आप में ठीक से काम करती हैं बल्कि इसके भीतर दोषपूर्ण उप-सुविधाएँ नहीं हैं। उदाहरण के लिए, यदि मैं एक्सपोनेंट फ़ंक्शन का परीक्षण कर रहा हूं और कुछ गलत हो रहा है, तो मुझे पता है कि बग शायद गुणन सबफीचर में नहीं है, क्योंकि गुणन फ़ंक्शन का पहले से ही बड़े पैमाने पर परीक्षण किया गया था। यह कोड की कुल मात्रा को समाप्त कर देता है जिसकी मुझे बग को खोजने के लिए बैकट्रेस और निरीक्षण करने की आवश्यकता होती है। उम्मीद है, यह तुच्छ उदाहरण स्पष्ट करता है कि यूनिट टेस्टिंग के आसपास विचार प्रक्रिया कैसे संरचित है। लेकिन यूनिट टेस्टिंग बाकी सॉफ्टवेयर डेवलपमेंट प्रोसेस के साथ कैसे इंटरैक्ट करती है? क्या होगा यदि आपके पास और भी जटिल विशेषताएं हैं, जिन्हें एक साथ काम करने और संवाद करने में सक्षम होने की आवश्यकता है? इकाई परीक्षण यह सुनिश्चित करने के लिए अपर्याप्त है कि ऐसी जटिल विशेषताएं एक साथ ठीक से काम कर सकें। वास्तव में, यह सॉफ्टवेयर परीक्षण के चार स्तरों का पहला चरण है (मैं बड़े अक्षरों का उपयोग करता हूं क्योंकि मैं उद्योग मानक या परीक्षण सॉफ्टवेयर के लिए सबसे आम दृष्टिकोण का उल्लेख करता हूं)। अंतिम तीन चरण हैंएकीकरण परीक्षण , सिस्टम परीक्षण और स्वीकृति परीक्षण. इन सभी का शायद वही मतलब है जो आपको लगता है कि वे करते हैं, लेकिन मुझे स्पष्ट करने दें: एकीकरण परीक्षण वह है जो हम ऊपर बताए गए "जटिल सुविधाओं" को आश्वस्त करने के लिए करेंगे, एक दूसरे के साथ ठीक से बातचीत करें। (उदाहरण के लिए, यह सुनिश्चित करना कि कैलकुलेटर "3 + 7 * 4 - 2" को संभाल सकता है) सिस्टम परीक्षण किसी विशेष प्रणाली के समग्र डिजाइन का परीक्षण कर रहा है; अक्सर एक उत्पाद में एक साथ काम करने वाली जटिल सुविधाओं की कई प्रणालियाँ होती हैं, इसलिए आप इन्हें सिस्टम में समूहित करते हैं और व्यक्तिगत रूप से उनका परीक्षण करते हैं। (उदाहरण के लिए, यदि आप एक रेखांकन कैलकुलेटर का निर्माण कर रहे थे, तो आप संख्याओं से निपटने के लिए पहले अंकगणितीय 'सिस्टम' का निर्माण करेंगे, तब तक परीक्षण करेंगे जब तक कि यह इरादा के अनुसार काम न करे, और फिर आप निकासी से निपटने के लिए ग्राफ़िंग 'सिस्टम' का निर्माण और परीक्षण करेंगे, जैसा कि यह अंकगणितीय प्रणाली का निर्माण करेगा)। स्वीकृति परीक्षण उपयोगकर्ता-स्तरीय परीक्षण है; यह देख रहा है कि क्या सभी सिस्टम उपयोगकर्ताओं द्वारा स्वीकार किए जाने के लिए तैयार तैयार उत्पाद बनाने के लिए सिंक में काम कर सकते हैं (उदाहरण के लिए, कैलकुलेटर का परीक्षण करने वाले उपयोगकर्ता)। सॉफ़्टवेयर डेवलपर कभी-कभी प्रक्रिया के इस अंतिम चरण को अनदेखा कर सकते हैं, क्योंकि कंपनियां अक्सर अन्य कर्मचारियों को उपयोगकर्ता (बीटा) परीक्षणों को अलग से तैनात करती हैं।

मैं जावा में जुनीट टेस्ट कैसे लिखूं?

अब जब आपको इकाई परीक्षण के लाभों और सीमाओं के बारे में स्पष्ट जानकारी हो गई है, तो आइए कुछ कोड देखें! हम जुनीट नामक एक लोकप्रिय जावा परीक्षण ढांचे का उपयोग करेंगे (एक अन्य लोकप्रिय टेस्टएनजी है, जिसे आप चाहें तो उपयोग कर सकते हैं। वे बहुत समान हैं, वाक्य रचनात्मक रूप से; टेस्टएनजी जुनीट से प्रेरित है)। आप यहां जूनिट को डाउनलोड और इंस्टॉल कर सकते हैं । इस उदाहरण कोड के लिए, हम 'वैज्ञानिक कैलकुलेटर' के उदाहरण को जारी रखेंगे जिसका मैं पहले उल्लेख कर रहा था; अपने सिर को चारों ओर लपेटना बहुत आसान है, और टेस्ट कोड बहुत आसान है। पारंपरिक अभ्यास आपकी प्रत्येक कक्षा के लिए अलग-अलग परीक्षा कक्षाएं लिखना है, इसलिए हम यही करेंगे। मान लेते हैं कि इस बिंदु पर, हमारे पास एक Math.javaफ़ाइल है जिसमें सभी गणित फ़ंक्शन (सहित Math.add) हैं, और हम एक लिख रहे हैंMathTests.javaएक ही पैकेज में फाइल करें। अब इम्पोर्ट स्टेटमेंट और क्लास बॉडी सेट अप करें: (संभावित जुनीट साक्षात्कार प्रश्न: आपसे पूछा जा सकता है कि अपना जुनीट परीक्षण कहां रखें और आपको अपनी स्रोत फाइलों को आयात करने की आवश्यकता है या नहीं। यदि आप अपनी परीक्षा कक्षाएं उसी पैकेज में लिख रहे हैं जैसे कि आपकी मुख्य कक्षाएं, तो आपको परीक्षण वर्ग में अपनी स्रोत फ़ाइलों के लिए किसी आयात विवरण की आवश्यकता नहीं है। अन्यथा, सुनिश्चित करें कि आप अपनी स्रोत फ़ाइलें आयात कर रहे हैं!)

import org.junit.jupiter.Test;    //gives us the @Test header
import static org.junit.jupiter.api.Assertions.assertEquals; //less typing :) 

public class MathTests {
	//...
}
पहला इम्पोर्ट स्टेटमेंट हमें @Testहेडर देता है। हम @Testहर टेस्ट फंक्शन डेफिनिशन के ऊपर सीधे '' लिखते हैं, ताकि JUnit को पता चले कि यह एक सिंगल यूनिट टेस्ट है जिसे अलग से चलाया जा सकता है। बाद में, मैं आपको दिखाऊंगा कि आप इस शीर्ष लेख का उपयोग करके विशिष्ट इकाई परीक्षण कैसे चला सकते हैं। दूसरा इम्पोर्ट स्टेटमेंट हमें टाइपिंग से थोड़ा बचाता है। हमारे कार्यों का परीक्षण करने के लिए हम जिस प्राथमिक JUnit फ़ंक्शन का उपयोग करते हैं, वह है Assert.assertEquals(), जो दो पैरामीटर (वास्तविक मान और अपेक्षित मान) लेता है और सुनिश्चित करता है कि वे समान हैं। यह दूसरा इम्पोर्ट स्टेटमेंट होने से हम assertEquals(...हर बार यह निर्दिष्ट करने के बजाय '' टाइप कर सकते हैं कि यह किस पैकेज का हिस्सा है। अब यह सत्यापित करने के लिए एक बहुत ही सरल परीक्षण केस लिखते हैं कि 2 + 2 वास्तव में 4 है!

import org.junit.jupiter.Test; // gives us the @Test header
import static org.junit.jupiter.api.Assertions.assertEquals; // less typing :) 


public class MathTests {
	@Test
	public void add_twoPlusTwo_returnsFour(){
	final int expected = 4;
	final int actual = Math.add(2, 2);
	assertEquals(“2+2 is 4”, actual, expected);
	}
}
आइए परीक्षण फ़ंक्शन की पांच पंक्तियों में से प्रत्येक पर जाएं और वे क्या करते हैं: पंक्ति 5: यह @Testशीर्षलेख निर्दिष्ट करता है कि नीचे दी गई फ़ंक्शन परिभाषा add_twoPlusTwo_returnsFour()वास्तव में एक परीक्षण फ़ंक्शन है जिसे जुनीट अलग से चला सकता है। लाइन 6: यह हमारे टेस्ट केस के लिए फंक्शन सिग्नेचर है। परीक्षण के मामले हमेशा बहुत विलक्षण होते हैं; वे केवल एक विशिष्ट उदाहरण का परीक्षण करते हैं, जैसे 2+2=4। अपने परीक्षण मामलों को "" के रूप में नाम देने की प्रथा है [function]_[params]_returns[expected](), जहां [function]आप जिस फ़ंक्शन का परीक्षण कर रहे हैं उसका नाम है, [params]आपके द्वारा परीक्षण किए जा रहे विशिष्ट उदाहरण पैरामीटर हैं, और [expected]फ़ंक्शन का अपेक्षित रिटर्न मान है। टेस्ट फ़ंक्शंस में लगभग हमेशा रिटर्न प्रकार होता है ' void' क्योंकि पूरे फ़ंक्शन का मुख्य बिंदु चलाना हैassertEquals, जो कंसोल को आउटपुट देगा कि आपका टेस्ट पास हुआ या नहीं; आपको कहीं भी लौटाने के लिए किसी अन्य डेटा की आवश्यकता नहीं है। पंक्ति 7: हम finalरिटर्न प्रकार के एक चर की घोषणा करते हैं Math.add (int), और इसे सम्मेलन द्वारा 'अपेक्षित' नाम देते हैं। इसका मूल्य वह उत्तर है जिसकी हम अपेक्षा कर रहे हैं (4)। पंक्ति 8: हम finalरिटर्न प्रकार के एक चर की घोषणा करते हैं Math.add (int), और इसे सम्मेलन द्वारा 'वास्तविक' नाम देते हैं। इसका मूल्य का परिणाम है Math.add(2, 2)। रेखा 9: सुनहरी रेखा। यह वह रेखा है जो वास्तविक और अपेक्षित की तुलना करती है और हमें बताती है कि हमने परीक्षा तभी उत्तीर्ण की जब वे समान हों। "2+2 is 4" पारित किया गया पहला पैरामीटर परीक्षण फ़ंक्शन का विवरण है।

क्या होगा यदि मेरे कार्य को अपवाद फेंकना चाहिए?

यदि आपके विशिष्ट परीक्षण उदाहरण को वास्तविक और अपेक्षित मान बराबर होने के बजाय अपवाद फेंकना चाहिए, तो JUnit के पास शीर्षलेख में इसे स्पष्ट करने का एक तरीका है @Test। आइए नीचे एक उदाहरण देखें। Math.javaयह मानते हुए कि हमारे पास कॉल में एक फ़ंक्शन है Math.divide, हम यह सुनिश्चित करना चाहते हैं कि इनपुट को 0. से विभाजित नहीं किया जा सकता है। इसके बजाय, Math.divide(a, 0)किसी भी 'ए' मान के लिए कॉल करने का प्रयास अपवाद ( ArithmeticException.class) फेंकना चाहिए। हम हेडर में इसे इस प्रकार निर्दिष्ट करते हैं:

import org.junit.jupiter.Test; // gives us the @Test header
import static org.junit.jupiter.api.Assertions.assertEquals; // less typing :) 


public class MathTests {
	@Test (expectedExceptions = ArithmeticException.class)
	public void divide_byZero_throwsException() throws ArithmeticException{
	Math.divide(1, 0);
	}
}
के लिए आपके पास एक से अधिक अपवाद हो सकते हैं expectedExceptions, बस अपनी अपवाद कक्षाओं को सूचीबद्ध करने के लिए कोष्ठक और अल्पविराम का उपयोग करना सुनिश्चित करें, जैसे:

expectedException = {FirstException.class, SecondException.class, … }

मैं जावा में अपने जुनीट परीक्षण कैसे चला सकता हूँ?

JUnit को IntelliJ में कैसे जोड़ें: https://stackoverflow.com/questions/19330832/setting-up-junit-with-intellij-idea आप अपनी परियोजना को वैसे ही चला सकते हैं जैसे आप सामान्य रूप से परीक्षण चलाते हैं। टेस्ट क्लास में सभी टेस्ट चलाना उन्हें वर्णानुक्रम में चलाएगा। @OrderJUnit 5 में, आप टैग जोड़कर परीक्षणों को प्राथमिकता दे सकते हैं । एक उदाहरण:

@TestMethodOrder(OrderAnnotation.class)
public class Tests {
…
@Test
@Order(2)
public void a_test() { … }

@Test
@Order (1)
public void b_test() { … }
…
}
भले ही वर्णानुक्रम में और कोड में a_test()पहले आता है , यहाँ से पहले चलेगा , क्योंकि 1 क्रम में 2 से पहले आता है। तो यह जुनीट की मूलभूत बातों के बारे में है। अब, आइए कुछ सामान्य JUnit साक्षात्कार प्रश्नों से निपटें, और JUnit के बारे में कुछ और जानें! b_test()b_test()a_test()

जूनिट साक्षात्कार प्रश्न (अतिरिक्त जानकारी)

यहाँ मैंने सबसे लोकप्रिय JUnit साक्षात्कार प्रश्न एकत्र किए हैं। यदि आपके पास जोड़ने के लिए कुछ है - नीचे टिप्पणी में ऐसा करने के लिए स्वतंत्र महसूस करें। प्रश्न: किसी परीक्षण को स्वचालित रूप से विफल करने के लिए आप अपनी परीक्षण पद्धति में किस विधि को कॉल कर सकते हैं? ए: असफल ("यहाँ त्रुटि विवरण!"); प्रश्न: आप डॉग क्लास का परीक्षण कर रहे हैं; डॉग ऑब्जेक्ट का परीक्षण करने के लिए, इससे पहले कि आप उस पर परीक्षण चला सकें, आपको उसे तुरंत चालू करना होगा। तो आप कुत्ते को तुरंत चालू करने के लिए एक सेटअप() फ़ंक्शन लिखते हैं। आप सभी परीक्षणों के दौरान केवल एक बार इस फ़ंक्शन को चलाना चाहते हैं। आपको सीधे सेटअप () फ़ंक्शन सिग्नेचर के ऊपर क्या रखना चाहिए ताकि JUnit परीक्षण चलाने से पहले सेटअप () चलाने के बारे में जान सके? A: @BeforeClass (@BeforeAll in JUnit 5) प्रश्न:ऊपर वर्णित सेटअप () फ़ंक्शन का फ़ंक्शन हस्ताक्षर क्या होना चाहिए? ए: सार्वजनिक स्थैतिक शून्य। @BeforeClass (JUnit 5 में @BeforeAll) या @AfterClass (@JUnit 5 में आफ्टरऑल) के साथ कोई भी फंक्शन स्थिर होना चाहिए। प्रश्न: आपने डॉग क्लास का परीक्षण कर लिया है। आप शून्य टियरडाउन () फ़ंक्शन लिखते हैं जो डेटा को साफ़ करता है और प्रत्येक परीक्षण के बाद सांत्वना देने के लिए जानकारी प्रिंट करता है। आप चाहते हैं कि यह फ़ंक्शन प्रत्येक परीक्षण के बाद चले। आपको टियरडाउन () फंक्शन सिग्नेचर के ऊपर सीधे क्या रखना चाहिए ताकि जुनीट प्रत्येक टेस्ट चलाने के बाद टियरडाउन () रन करना जान सके? ए: @ आफ्टर (जुनीट 5 में प्रत्येक के बाद)
टिप्पणियां
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION