इकाई परीक्षण के बारे में सब कुछ: तकनीक, अवधारणा, अभ्यास

आज आपको ऐसा कोई एप्लिकेशन नहीं मिलेगा जो परीक्षणों से लिपटा न हो, इसलिए यह विषय नौसिखिए डेवलपर्स के लिए पहले से कहीं अधिक प्रासंगिक होगा: आप परीक्षणों के बिना सफल नहीं हो सकते। आइए विचार करें कि सिद्धांत रूप में किस प्रकार के परीक्षण का उपयोग किया जाता है, और फिर हम इकाई परीक्षण के बारे में जानने के लिए हर चीज का विस्तार से अध्ययन करेंगे।

परीक्षण के प्रकार

एक परीक्षण क्या है? विकिपीडिया के अनुसार: "सॉफ्टवेयर परीक्षण में रुचि के एक या अधिक गुणों का मूल्यांकन करने के लिए एक सॉफ्टवेयर घटक या सिस्टम घटक का निष्पादन शामिल है।" दूसरे शब्दों में, यह कुछ स्थितियों में हमारे सिस्टम की शुद्धता की जाँच है। खैर, आइए देखें कि सामान्य तौर पर किस प्रकार के परीक्षण होते हैं:

• यूनिट टेस्टिंग — टेस्ट जिसका उद्देश्य सिस्टम के प्रत्येक मॉड्यूल की अलग से जांच करना है। ये परीक्षण सिस्टम के सबसे छोटे परमाणु भागों, जैसे मॉड्यूल पर लागू होने चाहिए।
• सिस्टम टेस्टिंग - एप्लिकेशन के एक बड़े हिस्से या पूरे सिस्टम के संचालन की जांच करने के लिए उच्च-स्तरीय परीक्षण।
• प्रतिगमन परीक्षण - परीक्षण जो यह जांचने के लिए प्रयोग किया जाता है कि क्या नई सुविधाएँ या बग फिक्स एप्लिकेशन की मौजूदा कार्यक्षमता को प्रभावित करते हैं या पुराने बग को पेश करते हैं।
• कार्यात्मक परीक्षण - यह जांचना कि क्या एप्लिकेशन का कोई हिस्सा विशिष्टताओं, उपयोगकर्ता कहानियों आदि में बताई गई आवश्यकताओं को पूरा करता है।

  कार्यात्मक परीक्षण के प्रकार:

  • व्हाइट-बॉक्स परीक्षण - सिस्टम के आंतरिक कार्यान्वयन को जानने के दौरान यह जांचना कि क्या एप्लिकेशन का एक हिस्सा आवश्यकताओं को पूरा करता है;
  • ब्लैक-बॉक्स परीक्षण - यह जांचना कि क्या एप्लिकेशन का एक हिस्सा सिस्टम के आंतरिक कार्यान्वयन को जाने बिना आवश्यकताओं को पूरा करता है।

• प्रदर्शन परीक्षण — परीक्षण जो यह निर्धारित करने के लिए लिखे जाते हैं कि सिस्टम या सिस्टम का हिस्सा एक निश्चित भार के तहत कैसा प्रदर्शन करता है।
• लोड टेस्टिंग — मानक लोड के तहत सिस्टम की स्थिरता की जांच करने के लिए डिज़ाइन किए गए टेस्ट और अधिकतम लोड का पता लगाने के लिए जिस पर एप्लिकेशन अभी भी ठीक से काम करता है।
• तनाव परीक्षण - गैर-मानक लोड के तहत एप्लिकेशन के प्रदर्शन की जांच करने और सिस्टम विफलता से पहले अधिकतम लोड निर्धारित करने के लिए डिज़ाइन किया गया परीक्षण।
• सुरक्षा परीक्षण — सिस्टम की सुरक्षा (हैकर्स, वायरस, गोपनीय डेटा तक अनधिकृत पहुंच और अन्य आकर्षक हमलों से) की जांच के लिए उपयोग किए जाने वाले परीक्षण।
• स्थानीयकरण परीक्षण — अनुप्रयोग के स्थानीयकरण का परीक्षण।
• प्रयोज्यता परीक्षण - प्रयोज्यता, समझ, आकर्षण और सीखने की क्षमता की जाँच करने के उद्देश्य से परीक्षण।

यह सब अच्छा लगता है, लेकिन व्यवहार में यह कैसे काम करता है? सरल! हम माइक कोहन के परीक्षण पिरामिड का उपयोग करते हैं: यह पिरामिड का सरलीकृत संस्करण है: इसे अब और भी छोटे भागों में विभाजित किया गया है। लेकिन आज हम बहुत परिष्कृत नहीं होंगे। हम सबसे सरल संस्करण पर विचार करेंगे।

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

   इनमें से बहुत सारे परीक्षण हमेशा होने चाहिए (किसी भी अन्य प्रकार से अधिक), क्योंकि वे छोटे टुकड़ों का परीक्षण करते हैं और बहुत हल्के होते हैं, बहुत सारे संसाधनों (मतलब रैम और समय) का उपभोग नहीं करते हैं।

2. एकीकरण - यह खंड एकीकरण परीक्षण को संदर्भित करता है। यह परीक्षण सिस्टम के बड़े टुकड़ों की जाँच करता है। यही है, यह या तो तर्क के कई टुकड़ों (कई विधियों या वर्गों) को जोड़ता है, या यह बाहरी घटक के साथ बातचीत की शुद्धता की जांच करता है। ये परीक्षण आमतौर पर इकाई परीक्षणों से छोटे होते हैं क्योंकि ये भारी होते हैं।

   एकीकरण परीक्षण का एक उदाहरण एक डेटाबेस से जुड़ना और इसके साथ काम करने के तरीकों के संचालन की शुद्धता की जाँच करना हो सकता है।

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

   ऊपर की तस्वीर में, हम देखते हैं कि त्रिभुज के विभिन्न भाग आकार में भिन्न होते हैं: वास्तविक कार्य में विभिन्न प्रकार के परीक्षणों की संख्या में लगभग समान अनुपात मौजूद होते हैं।

   आज हम सबसे सामान्य परीक्षण, इकाई परीक्षण पर करीब से नज़र डालेंगे, क्योंकि सभी स्वाभिमानी जावा डेवलपर्स को बुनियादी स्तर पर उनका उपयोग करने में सक्षम होना चाहिए।

इकाई परीक्षण में मुख्य अवधारणाएँ

परीक्षण कवरेज (कोड कवरेज) एक आवेदन का परीक्षण कितनी अच्छी तरह से किया जाता है, इसका एक मुख्य उपाय है। यह कोड का प्रतिशत है जो परीक्षणों (0-100%) द्वारा कवर किया गया है। व्यवहार में, कई लोग इस प्रतिशत को अपने लक्ष्य के रूप में अपना रहे हैं। यह ऐसी चीज है जिससे मैं असहमत हूं, क्योंकि इसका मतलब है कि जहां परीक्षण की जरूरत नहीं है, वहां परीक्षण लागू होने लगते हैं। उदाहरण के लिए, मान लें कि हमारे पास अतिरिक्त तर्क के बिना हमारी सेवा में मानक CRUD (क्रिएट/गेट/अपडेट/डिलीट) ऑपरेशन हैं। ये विधियाँ विशुद्ध रूप से मध्यस्थ हैं जो रिपॉजिटरी के साथ काम करने वाली परत को काम सौंपती हैं। इस स्थिति में, हमारे पास परीक्षण करने के लिए कुछ भी नहीं है, सिवाय इसके कि क्या दी गई विधि DAO विधि कहलाती है, लेकिन यह एक मज़ाक है। अतिरिक्त उपकरणों का आमतौर पर परीक्षण कवरेज का आकलन करने के लिए उपयोग किया जाता है: जाकोको, कोबर्टुरा, क्लोवर, एम्मा, आदि। इस विषय के अधिक विस्तृत अध्ययन के लिए,

• माध्यम पर कोड कवरेज
• ब्लैक बॉक्स परीक्षण: उदाहरणों और तकनीकों के साथ गहन ट्यूटोरियल

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

• हम अपना परीक्षण लिखते हैं।
• हम परीक्षण चलाते हैं। अप्रत्याशित रूप से, यह विफल हो जाता है, क्योंकि हमने अभी तक आवश्यक तर्क को लागू नहीं किया है।
• वह कोड जोड़ें जो परीक्षण को पास करने का कारण बनता है (हम फिर से परीक्षण चलाते हैं)।
• हम कोड को रिफलेक्टर करते हैं।

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

परीक्षण के चरण

एक परीक्षण में तीन चरण होते हैं:

• परीक्षण डेटा (जुड़नार) निर्दिष्ट करें।
• परीक्षण के तहत कोड का प्रयोग करें (परीक्षण विधि को कॉल करें)।
• परिणामों की जाँच करें और अपेक्षित परिणामों के साथ तुलना करें।

परीक्षण मॉड्यूलरिटी सुनिश्चित करने के लिए, आपको एप्लिकेशन की अन्य परतों से अलग करने की आवश्यकता है। यह स्टब्स, मॉक और जासूसों का उपयोग करके किया जा सकता है। मोक्स ऐसी वस्तुएँ हैं जिन्हें अनुकूलित किया जा सकता है (उदाहरण के लिए, प्रत्येक परीक्षण के लिए सिलवाया गया)। वे हमें निर्दिष्ट करते हैं कि हम विधि कॉल से क्या अपेक्षा करते हैं, अर्थात अपेक्षित प्रतिक्रियाएँ। हम नकली वस्तुओं का उपयोग यह सत्यापित करने के लिए करते हैं कि हमें वह मिलता है जिसकी हम अपेक्षा करते हैं। स्टब्स परीक्षण के दौरान कॉल के लिए हार्ड-कोडेड प्रतिक्रिया प्रदान करते हैं। वे कॉल के बारे में जानकारी भी संग्रहीत कर सकते हैं (उदाहरण के लिए, पैरामीटर या कॉल की संख्या)। इन्हें कभी-कभी जासूस भी कहा जाता है। कभी-कभी लोग स्टब और मॉक शब्दों को भ्रमित करते हैं: अंतर यह है कि स्टब किसी भी चीज़ की जाँच नहीं करता है - यह केवल किसी दिए गए राज्य का अनुकरण करता है। मॉक एक ऐसी वस्तु है जिसमें अपेक्षाएं होती हैं। उदाहरण के लिए, किसी दिए गए तरीके को एक निश्चित संख्या में कॉल किया जाना चाहिए। दूसरे शब्दों में,

परीक्षण वातावरण

तो, अब मुद्दे पर। जावा के लिए कई परीक्षण वातावरण (ढांचे) उपलब्ध हैं। इनमें से सबसे लोकप्रिय JUnit और TestNG हैं। यहाँ हमारी समीक्षा के लिए, हम उपयोग करते हैं: एक JUnit परीक्षण एक कक्षा में एक विधि है जिसका उपयोग केवल परीक्षण के लिए किया जाता है। कक्षा को आम तौर पर उसी वर्ग के रूप में नामित किया जाता है जिसे वह परीक्षण करता है, अंत में "टेस्ट" जोड़ा जाता है। उदाहरण के लिए, CarService -> CarServiceTest। मेवेन बिल्ड सिस्टम स्वचालित रूप से ऐसी कक्षाओं को टेस्ट स्कोप में शामिल करता है। दरअसल, इस क्लास को टेस्ट क्लास कहा जाता है। आइए संक्षेप में मूल एनोटेशन पर जाएं:

• @Test इंगित करता है कि विधि एक परीक्षण है (मूल रूप से, इस एनोटेशन के साथ चिह्नित विधि एक इकाई परीक्षण है)।
• @ इससे पहले एक विधि को इंगित करता है जिसे प्रत्येक परीक्षण से पहले निष्पादित किया जाएगा। उदाहरण के लिए, परीक्षण डेटा के साथ कक्षा को पॉप्युलेट करने के लिए, इनपुट डेटा पढ़ें आदि।
• @ के बाद एक विधि को चिह्नित करने के लिए उपयोग किया जाता है जिसे प्रत्येक परीक्षण के बाद बुलाया जाएगा (उदाहरण के लिए डेटा को साफ़ करने या डिफ़ॉल्ट मानों को पुनर्स्थापित करने के लिए)।
• @BeforeClass एक विधि के ऊपर रखा गया है, जो @Before के अनुरूप है। लेकिन इस तरह की विधि को दिए गए वर्ग के सभी परीक्षणों से पहले केवल एक बार कहा जाता है और इसलिए स्थिर होना चाहिए। इसका उपयोग अधिक संसाधन-गहन संचालन करने के लिए किया जाता है, जैसे परीक्षण डेटाबेस को कताई करना।
• @AfterClass @BeforeClass के विपरीत है: इसे दिए गए वर्ग के लिए एक बार निष्पादित किया जाता है, लेकिन केवल सभी परीक्षणों के बाद। इसका उपयोग, उदाहरण के लिए, लगातार संसाधनों को साफ़ करने या डेटाबेस से डिस्कनेक्ट करने के लिए किया जाता है।
• @ इग्नोर इंगित करता है कि एक विधि अक्षम है और समग्र परीक्षण चलाने के दौरान इसे अनदेखा कर दिया जाएगा। इसका उपयोग विभिन्न स्थितियों में किया जाता है, उदाहरण के लिए, यदि आधार पद्धति बदल दी गई है और परिवर्तनों को समायोजित करने के लिए परीक्षण पर अभी तक कार्य नहीं किया गया है। ऐसे मामलों में, विवरण जोड़ना भी वांछनीय है, अर्थात @Ignore("कुछ विवरण")।
• @Test(expected = Exception.class) नकारात्मक परीक्षणों के लिए प्रयोग किया जाता है। ये वे परीक्षण हैं जो सत्यापित करते हैं कि त्रुटि के मामले में विधि कैसे व्यवहार करती है, अर्थात, परीक्षण किसी प्रकार के अपवाद को फेंकने की विधि की अपेक्षा करता है। इस तरह की विधि @Test एनोटेशन द्वारा इंगित की जाती है, लेकिन किस त्रुटि को पकड़ने के संकेत के साथ।
• @ टेस्ट (टाइमआउट = 100) जांचता है कि विधि 100 मिलीसेकंड से अधिक में निष्पादित नहीं हुई है।
• @Mock का उपयोग किसी फ़ील्ड के ऊपर मॉक ऑब्जेक्ट असाइन करने के लिए किया जाता है (यह JUnit एनोटेशन नहीं है, बल्कि मॉकिटो से आता है)। आवश्यकतानुसार, हम मॉक के व्यवहार को सीधे टेस्ट मेथड में एक विशिष्ट स्थिति के लिए सेट करते हैं।
• @RunWith(MockitoJUnitRunner.class) एक वर्ग के ऊपर रखा गया है। यह एनोटेशन JUnit को कक्षा में परीक्षण शुरू करने के लिए कहता है। इनमें से कई धावक हैं: MockitoJUnitRunner, JUnitPlatform, और SpringRunner। JUnit 5 में, @RunWith एनोटेशन को अधिक शक्तिशाली @ExtendWith एनोटेशन से बदल दिया गया है।

आइए परिणामों की तुलना करने के लिए उपयोग की जाने वाली कुछ विधियों पर एक नज़र डालें:

• AssertEquals (ऑब्जेक्ट अपेक्षित, ऑब्जेक्ट वास्तविक) - जाँचता है कि पास की गई वस्तुएँ समान हैं या नहीं।
• AssertTrue (बूलियन फ़्लैग) - चेक करता है कि पास किया गया मान सही है या नहीं।
• AssertFalse (बूलियन फ्लैग) - जाँचता है कि क्या पास किया गया मान गलत है।
• AssertNull (ऑब्जेक्ट ऑब्जेक्ट) - चेक करता है कि पास की गई वस्तु शून्य है या नहीं।
• AssertSame(ऑब्जेक्ट फर्स्टऑब्जेक्ट, ऑब्जेक्ट सेकेंडऑब्जेक्ट) - चेक करता है कि पास किए गए मान एक ही ऑब्जेक्ट को संदर्भित करते हैं या नहीं।
• जोर दें (टी टी, मैचर मैचर) - जाँचता है कि क्या टी मैचर में निर्दिष्ट शर्तों को पूरा करता है।

AssertJ एक उपयोगी तुलना विधि भी प्रदान करता है: assertThat(firstObject).isEqualTo(secondObject) । यहाँ मैंने मूलभूत विधियों का उल्लेख किया है — अन्य उपरोक्त के रूपांतर हैं।

व्यवहार में परीक्षण

अब आइए उपरोक्त सामग्री को एक विशिष्ट उदाहरण में देखें। हम सेवा की अद्यतन विधि का परीक्षण करेंगे। हम डीएओ परत पर विचार नहीं करेंगे, क्योंकि हम डिफ़ॉल्ट का उपयोग कर रहे हैं। आइए परीक्षणों के लिए स्टार्टर जोड़ें:

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-test</artifactId>
   <version>2.2.2.RELEASE</version>
   <scope>test</scope>
</dependency>

और यहाँ हमारे पास सेवा वर्ग है:

@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
   private final RobotDAO robotDAO;

   @Override
   public Robot update(Long id, Robot robot) {
       Robot found = robotDAO.findById(id);
       return robotDAO.update(Robot.builder()
               .id(id)
               .name(robot.getName() != null ? robot.getName() : found.getName())
               .cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
               .producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
               .build());
   }
}

पंक्ति 8 - अद्यतन वस्तु को डेटाबेस से खींचें। लाइन्स 9-14 - बिल्डर के माध्यम से एक ऑब्जेक्ट बनाएं। यदि आने वाली वस्तु में कोई फ़ील्ड है, तो उसे सेट करें। यदि नहीं, तो हम डेटाबेस में जो है उसे छोड़ देंगे। अब हमारा परीक्षण देखें:

@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
   @Mock
   private RobotDAO robotDAO;

   private RobotServiceImpl robotService;

   private static Robot testRobot;

   @BeforeClass
   public static void prepareTestData() {
       testRobot = Robot
               .builder()
               .id(123L)
               .name("testRobotMolly")
               .cpu("Intel Core i7-9700K")
               .producer("China")
               .build();
   }

   @Before
   public void init() {
       robotService = new RobotServiceImpl(robotDAO);
   }

पंक्ति 1 - हमारा धावक। पंक्ति 4 - हम नकली को प्रतिस्थापित करके सेवा को DAO परत से अलग करते हैं। पंक्ति 11 - हम कक्षा के लिए एक परीक्षण इकाई (जिसे हम गिनी पिग के रूप में उपयोग करेंगे) सेट करते हैं। लाइन 22 - हम सर्विस ऑब्जेक्ट सेट करते हैं, जिसे हम टेस्ट करेंगे।

@Test
public void updateTest() {
   when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
   when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
   Robot robotForUpdate = Robot
           .builder()
           .name("Vally")
           .cpu("AMD Ryzen 7 2700X")
           .build();

   Robot resultRobot = robotService.update(123L, robotForUpdate);

   assertNotNull(resultRobot);
   assertSame(resultRobot.getId(),testRobot.getId());
   assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
   assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
   assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}

यहाँ हम देखते हैं कि परीक्षण के तीन स्पष्ट भाग हैं: रेखाएँ 3-9 — फिक्स्चर निर्दिष्ट करना। लाइन 11 - परीक्षण के तहत कोड निष्पादित करना। लाइन्स 13-17 - परिणामों की जाँच करना। अधिक विवरण में: लाइन्स 3-4 — DAO मॉक के लिए व्यवहार सेट करें। पंक्ति 5 - वह उदाहरण सेट करें जिसे हम अपने मानक के शीर्ष पर अपडेट करेंगे। पंक्ति 11 - विधि का उपयोग करें और परिणामी उदाहरण लें। रेखा 13 - जांचें कि यह शून्य नहीं है। रेखा 14 - परिणाम की आईडी और दिए गए विधि तर्कों की तुलना करें। लाइन 15 - जांचें कि नाम अपडेट किया गया था या नहीं। लाइन 16 - CPU परिणाम देखें। रेखा 17 - हमने इस क्षेत्र को उदाहरण में निर्दिष्ट नहीं किया है, इसलिए इसे वही रहना चाहिए। हम यहां उस स्थिति की जांच करते हैं। आइए इसे चलाते हैं:परीक्षा हरी है! हम राहत की सांस ले सकते हैं :) संक्षेप में, परीक्षण कोड की गुणवत्ता में सुधार करता है और विकास प्रक्रिया को अधिक लचीला और भरोसेमंद बनाता है। कल्पना कीजिए कि सैकड़ों क्लास फाइलों वाले सॉफ़्टवेयर को फिर से डिज़ाइन करने में कितना प्रयास करना पड़ता है। जब हमारे पास इन सभी वर्गों के लिए लिखित इकाई परीक्षण होते हैं, तो हम विश्वास के साथ रिफ्लेक्टर कर सकते हैं। और सबसे महत्वपूर्ण बात यह है कि यह विकास के दौरान बग को आसानी से ढूंढने में हमारी सहायता करता है। दोस्तों और लड़कियों, आज मेरे पास बस इतना ही है। मुझे लाइक करें और कमेंट करें :)